Network Working Group I. Friend
Request for Comments: 5024 ODETTE
Obsoletes: 2204 November 2007
Category: Informational
Network Working Group I. Friend
Request for Comments: 5024 ODETTE
Obsoletes: 2204 November 2007
Category: Informational
ODETTE File Transfer Protocol 2
ODETTE文件传输协议2
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。有关更多信息，请参阅RFC 3932。
Abstract
摘要
This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.
本备忘录将ODETTE文件传输协议（一种促进贸易伙伴之间业务数据电子数据交换的文件传输协议）更新为第2版。
The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files.
该协议现在支持使用传输层安全性在Internet上进行安全和经过身份验证的通信，使用加密消息语法提供文件加密、签名和压缩，并为接收文件的确认提供签名收据。
The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25, and ISDN-based networks.
该协议支持直接对等通信和通过增值网络进行的间接通信，并可用于基于TCP/IP、X.25和ISDN的网络。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Background .................................................4
1.2. Summary of Features ........................................5
1.3. General Principles .........................................5
1.4. Structure ..................................................6
1.5. Virtual Files ..............................................6
1.6. Service Description ........................................9
1.7. Security ...................................................9
2. Network Service ................................................11
2.1. Introduction ..............................................11
2.2. Service Primitives ........................................11
2.3. Secure ODETTE-FTP Session .................................12
2.4. Port Assignment ...........................................12
3. File Transfer Service ..........................................13
3.1. Model .....................................................13
3.2. Session Setup .............................................14
3.3. File Transfer .............................................16
3.4. Session Take Down .........................................20
3.5. Service State Automata ....................................23
4. Protocol Specification .........................................28
4.1. Overview ..................................................28
4.2. Start Session Phase .......................................28
4.3. Start File Phase ..........................................30
4.4. Data Transfer Phase .......................................34
4.5. End File Phase ............................................35
4.6. End Session Phase .........................................36
4.7. Problem Handling ..........................................36
5. Commands and Formats ...........................................37
5.1. Conventions ...............................................37
5.2. Commands ..................................................37
5.3. Command Formats ...........................................37
5.4. Identification Code .......................................68
6. File Services ..................................................69
6.1. Overview ..................................................69
6.2. File Signing ..............................................69
6.3. File Encryption ...........................................70
6.4. File Compression ..........................................70
6.5. V Format Files - Record Lengths ...........................70
7. ODETTE-FTP Data Exchange Buffer ................................71
7.1. Overview ..................................................71
7.2. Data Exchange Buffer Format ...............................71
7.3. Buffer Filling Rules ......................................72
8. Stream Transmission Buffer .....................................73
8.1. Introduction ..............................................73
8.2. Stream Transmission Header Format .........................73
1. Introduction ....................................................4
1.1. Background .................................................4
1.2. Summary of Features ........................................5
1.3. General Principles .........................................5
1.4. Structure ..................................................6
1.5. Virtual Files ..............................................6
1.6. Service Description ........................................9
1.7. Security ...................................................9
2. Network Service ................................................11
2.1. Introduction ..............................................11
2.2. Service Primitives ........................................11
2.3. Secure ODETTE-FTP Session .................................12
2.4. Port Assignment ...........................................12
3. File Transfer Service ..........................................13
3.1. Model .....................................................13
3.2. Session Setup .............................................14
3.3. File Transfer .............................................16
3.4. Session Take Down .........................................20
3.5. Service State Automata ....................................23
4. Protocol Specification .........................................28
4.1. Overview ..................................................28
4.2. Start Session Phase .......................................28
4.3. Start File Phase ..........................................30
4.4. Data Transfer Phase .......................................34
4.5. End File Phase ............................................35
4.6. End Session Phase .........................................36
4.7. Problem Handling ..........................................36
5. Commands and Formats ...........................................37
5.1. Conventions ...............................................37
5.2. Commands ..................................................37
5.3. Command Formats ...........................................37
5.4. Identification Code .......................................68
6. File Services ..................................................69
6.1. Overview ..................................................69
6.2. File Signing ..............................................69
6.3. File Encryption ...........................................70
6.4. File Compression ..........................................70
6.5. V Format Files - Record Lengths ...........................70
7. ODETTE-FTP Data Exchange Buffer ................................71
7.1. Overview ..................................................71
7.2. Data Exchange Buffer Format ...............................71
7.3. Buffer Filling Rules ......................................72
8. Stream Transmission Buffer .....................................73
8.1. Introduction ..............................................73
8.2. Stream Transmission Header Format .........................73
9. Protocol State Machine .........................................74
9.1. ODETTE-FTP State Machine ..................................74
9.2. Error Handling ............................................75
9.3. States ....................................................76
9.4. Input Events ..............................................79
9.5. Output Events .............................................79
9.6. Local Variables ...........................................80
9.7. Local Constants ...........................................81
9.8. Session Connection State Table ............................82
9.9. Error and Abort State Table ...............................85
9.10. Speaker State Table 1 ....................................86
9.11. Speaker State Table 2 ....................................91
9.12. Listener State Table .....................................93
9.13. Example ..................................................96
10. Miscellaneous .................................................97
10.1. Algorithm Choice .........................................97
10.2. Cryptographic Algorithms .................................97
10.3. Protocol Extensions ......................................97
10.4. Certificate Services .....................................98
11. Security Considerations .......................................98
Appendix A. Virtual File Mapping Example .........................100
Appendix B. ISO 646 Character Subset .............................103
Appendix C. X.25 Specific Information ............................104
C.1. X.25 Addressing Restrictions .............................104
C.2. Special Logic ............................................105
C.3. PAD Parameter Profile ....................................116
Appendix D. OFTP X.25 Over ISDN Recommendation ...................118
D.1. ODETTE ISDN Recommendation ...............................119
D.2. Introduction to ISDN .....................................120
D.3. Equipment Types ..........................................123
D.4. Implementation ...........................................124
Acknowledgements .................................................132
Normative References .............................................132
Informative References ...........................................133
ODETTE Address ...................................................134
9. Protocol State Machine .........................................74
9.1. ODETTE-FTP State Machine ..................................74
9.2. Error Handling ............................................75
9.3. States ....................................................76
9.4. Input Events ..............................................79
9.5. Output Events .............................................79
9.6. Local Variables ...........................................80
9.7. Local Constants ...........................................81
9.8. Session Connection State Table ............................82
9.9. Error and Abort State Table ...............................85
9.10. Speaker State Table 1 ....................................86
9.11. Speaker State Table 2 ....................................91
9.12. Listener State Table .....................................93
9.13. Example ..................................................96
10. Miscellaneous .................................................97
10.1. Algorithm Choice .........................................97
10.2. Cryptographic Algorithms .................................97
10.3. Protocol Extensions ......................................97
10.4. Certificate Services .....................................98
11. Security Considerations .......................................98
Appendix A. Virtual File Mapping Example .........................100
Appendix B. ISO 646 Character Subset .............................103
Appendix C. X.25 Specific Information ............................104
C.1. X.25 Addressing Restrictions .............................104
C.2. Special Logic ............................................105
C.3. PAD Parameter Profile ....................................116
Appendix D. OFTP X.25 Over ISDN Recommendation ...................118
D.1. ODETTE ISDN Recommendation ...............................119
D.2. Introduction to ISDN .....................................120
D.3. Equipment Types ..........................................123
D.4. Implementation ...........................................124
Acknowledgements .................................................132
Normative References .............................................132
Informative References ...........................................133
ODETTE Address ...................................................134
The ODETTE File Transfer Protocol (ODETTE-FTP) was defined in 1986 by working group four of the Organisation for Data Exchange by Tele Transmission in Europe (ODETTE) to address the electronic data interchange (EDI) requirements of the European automotive industry.
ODETTE文件传输协议（ODETTE-FTP）由欧洲远程传输数据交换组织（ODETTE）第四工作组于1986年定义，以满足欧洲汽车行业的电子数据交换（EDI）要求。
ODETTE-FTP allows business applications to exchange files on a peer-to-peer basis in a standardised, purely automatic manner and provides a defined acknowledgement process on successful receipt of a file.
ODETTE-FTP允许业务应用程序以标准化、纯自动的方式在点对点的基础上交换文件，并在成功接收文件时提供定义的确认过程。
ODETTE-FTP is not to be confused as a variant of, or similar to, the Internet FTP [FTP], which provides an interactive means for individuals to share files and which does not have any sort of acknowledgement process. By virtue of its interactive nature, lack of file acknowledgements, and client/server design, FTP does not easily lend itself to mission-critical environments for the exchange of business data.
ODETTE-FTP不应被混淆为Internet FTP[FTP]的变体或类似物，它为个人共享文件提供了一种交互方式，并且没有任何形式的确认过程。由于其交互性质、缺少文件确认和客户机/服务器设计，FTP不容易将其自身用于业务数据交换的关键任务环境。
Over the last ten years, ODETTE-FTP has been widely deployed on systems of all sizes from personal computers to large mainframes while the Internet has emerged as the dominant international network, providing high-speed communication at low cost. To match the demand for EDI over the Internet, ODETTE has decided to extend the scope of its file transfer protocol to incorporate security functions and advanced compression techniques to ensure that it remains at the forefront of information exchange technology.
在过去十年中，ODETTE-FTP已广泛部署在从个人计算机到大型主机的各种规模的系统上，而互联网已成为主导的国际网络，以低成本提供高速通信。为了满足互联网上对EDI的需求，ODETTE决定扩大其文件传输协议的范围，以纳入安全功能和先进的压缩技术，以确保其始终处于信息交换技术的前沿。
The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files.
该协议现在支持使用传输层安全性在Internet上进行安全和经过身份验证的通信，使用加密消息语法提供文件加密、签名和压缩，并为接收文件的确认提供签名收据。
The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25 and ISDN based networks.
该协议支持直接对等通信和通过增值网络进行的间接通信，并可用于基于TCP/IP、X.25和ISDN的网络。
ODETTE-FTP has been defined by the ODETTE Security Working Group which consists of a number of ODETTE member organisations. All members have significant operational experience working with and developing OFTP and EDI solutions.
ODETTE-FTP由ODETTE安全工作组定义，该工作组由多个ODETTE成员组织组成。所有成员都拥有丰富的运营经验，能够使用和开发OFTP和EDI解决方案。
This memo is a development of version 1.4 of ODETTE-FTP [OFTP] with these changes/additions:
本备忘录是ODETTE-FTP[OFTP]1.4版的发展，包括以下更改/增补：
Session level encryption File level encryption Secure authentication File compression Signed End to End Response (EERP) Signed Negative End Response (NERP) Maximum permitted file size increased to 9 PB (petabytes) Virtual file description added Extended error codes
会话级加密文件级加密安全身份验证文件压缩签名端到端响应（EERP）签名负端响应（NERP）最大允许文件大小增加到9 PB（PB）虚拟文件描述添加扩展错误代码
Version 1.4 of ODETTE-FTP included these changes and additions to version 1.3:
ODETTE-FTP的1.4版包括对1.3版的这些更改和添加：
Negative End Response (NERP) Extended Date and Time stamp New reason code 14 (File direction refused)
否定结束响应（NERP）延长日期和时间戳新原因代码14（文件方向被拒绝）
The aim of ODETTE-FTP is to facilitate the transmission of a file between one or more locations in a way that is independent of the data communication network, system hardware, and software environment.
ODETTE-FTP的目的是以独立于数据通信网络、系统硬件和软件环境的方式促进文件在一个或多个位置之间的传输。
In designing and specifying the protocol, the following factors were considered.
在设计和指定协议时，考虑了以下因素。
1. The possible differences of size and sophistication of file storage and small and large systems.
1. 文件存储和大小系统在大小和复杂度方面可能存在的差异。
2. The necessity to work with existing systems (reduce changes to existing products and allow easy implementation).
2. 使用现有系统的必要性（减少对现有产品的更改并允许轻松实施）。
3. Systems of different ages.
3. 不同时代的系统。
4. Systems of different manufactures.
4. 不同制造商的系统。
5. The potential for growth in sophistication (limit impact and avoid changes at other locations).
5. 成熟度增长的潜力（限制影响并避免在其他位置发生变化）。
ODETTE-FTP is modelled on the OSI reference model. It is designed to use the Network Service provided by level 3 of the model and provide a File Service to the users. Thus, the protocol spans levels 4 to 7 of the model.
ODETE-FTP是以OSI参考模型为模型的。它的设计目的是使用模型第3级提供的网络服务，并向用户提供文件服务。因此，协议跨越模型的4到7级。
The description of ODETTE-FTP contained in this memo is closely related to the original 'X.25' specification of the protocol and in the spirit of the OSI model describes:
本备忘录中对ODETTE-FTP的描述与协议的原始“X.25”规范密切相关，并本着OSI模型的精神描述：
1. A File Service provided to a User Monitor.
1. 提供给用户监视器的文件服务。
2. A protocol for the exchange of information between peer ODETTE-FTP entities.
2. 对等ODETE-FTP实体之间交换信息的协议。
Information is always exchanged between ODETTE-FTP entities in a standard representation called a Virtual File. This allows data transfer without regard for the nature of the communicating systems.
信息始终以称为虚拟文件的标准表示形式在ODETTE-FTP实体之间交换。这允许在不考虑通信系统性质的情况下进行数据传输。
The mapping of a file between a local and virtual representation will vary from system to system and is not defined here.
本地表示和虚拟表示之间的文件映射因系统而异，此处未定义。
o---------o
Site | Local |
A | File A |
o---------o
|
o----------------------- Mapping A ------------------------o
| | |
| o---------o |
| | Virtual | |
| | File | |
| o---------o |
| o------------------------------------------------o |
| | | |
| | ODETTE-FTP | |
| | | |
| o------------------------------------------------o |
| o---------o o---------o |
| | Virtual | | Virtual | |
| | File | | File | |
| o---------o o----+----o |
| | | |
o------ Mapping B ------------------------ Mapping C ------o
| |
o---------o o----+----o
| Local | Site Site | Local |
| File B | B C | File C |
o---------o o---------o
o---------o
Site | Local |
A | File A |
o---------o
|
o----------------------- Mapping A ------------------------o
| | |
| o---------o |
| | Virtual | |
| | File | |
| o---------o |
| o------------------------------------------------o |
| | | |
| | ODETTE-FTP | |
| | | |
| o------------------------------------------------o |
| o---------o o---------o |
| | Virtual | | Virtual | |
| | File | | File | |
| o---------o o----+----o |
| | | |
o------ Mapping B ------------------------ Mapping C ------o
| |
o---------o o----+----o
| Local | Site Site | Local |
| File B | B C | File C |
o---------o o---------o
A Virtual File is described by a set of attributes identifying and defining the data to be transferred. The main attributes are detailed in Sections 1.5.1 to 1.5.4.
虚拟文件由一组标识和定义要传输的数据的属性来描述。主要属性详见第1.5.1节至第1.5.4节。
Sequential
顺序的
Logical records are presented one after another. ODETTE-FTP must be aware of the record boundaries.
逻辑记录一个接一个地呈现。ODETTE-FTP必须了解记录边界。
Dataset Name
数据集名称
Dataset name of the Virtual File being transferred, assigned by bilateral agreement.
正在传输的虚拟文件的数据集名称，由双边协议指定。
Time stamp (HHMMSScccc)
时间戳（HHMMSScccc）
A file qualifier indicating the time the Virtual File was made available for transmission. The counter (cccc=0001-9999) gives higher resolution.
文件限定符，指示虚拟文件可用于传输的时间。计数器（cccc=0001-9999）具有更高的分辨率。
Date stamp (CCYYMMDD)
日期戳（CCYYMMDD）
A file qualifier indicating the date the Virtual File was made available for transmission.
文件限定符，指示虚拟文件可用于传输的日期。
The Dataset Name, Date, and Time attributes are assigned by the Virtual File's originator and are used to uniquely identify a file. They are all mandatory and must not be changed by intermediate locations.
数据集名称、日期和时间属性由虚拟文件的发起人指定，用于唯一标识文件。它们都是强制性的，中间位置不得更改。
The User Monitor may use the Virtual File Date and Time attributes in local processes involving date comparisons and calculations. Any such use falls outside the scope of this protocol.
用户监视器可以在涉及日期比较和计算的本地进程中使用虚拟文件日期和时间属性。任何此类使用不属于本协议的范围。
Four record formats are defined:
定义了四种记录格式：
Fixed (F)
固定（F）
Each record in the file has the same length.
文件中的每条记录都具有相同的长度。
Variable (V)
变量（V）
The records in the file can have different lengths.
文件中的记录可以有不同的长度。
Unstructured (U)
非结构化（U）
The file contains a stream of data. No structure is defined.
该文件包含一个数据流。没有定义任何结构。
Text File (T)
文本文件（T）
A Text File is defined as a sequence of ASCII characters, containing no control characters except CR-LF that delimit lines. A line will not have more than 2048 characters.
文本文件定义为ASCII字符序列，不包含任何控制字符，除了分隔行的CR-LF字符。一行不能超过2048个字符。
ODETTE-FTP can negotiate the restart of an interrupted Virtual File transmission. Fixed and Variable format files are restarted on record boundaries. For Unstructured and Text files, the restart position is expressed as a file offset in 1K (1024 octet) blocks.
ODETTE-FTP可以协商重启中断的虚拟文件传输。固定格式和可变格式文件在记录边界上重新启动。对于非结构化文件和文本文件，重新启动位置表示为1K（1024个八位字节）块中的文件偏移量。
The restart position is always calculated relative to the start of the Virtual File.
重新启动位置始终是相对于虚拟文件的开始计算的。
ODETTE-FTP provides a file transfer service to a User Monitor and in turn uses the Internet transport layer stream service to communicate between peers.
ODETTE-FTP向用户监视器提供文件传输服务，并反过来使用Internet传输层流服务在对等点之间进行通信。
These services are specified in this memo using service primitives grouped into four classes as follows:
这些服务在本备忘录中使用分成以下四类的服务原语指定：
Request (RQ) An entity asks the service to do some work. Indication (IND) A service informs an entity of an event. Response (RS) An entity responds to an event. Confirm (CF) A service informs an entity of the response.
请求（RQ）实体请求服务做一些工作。指示（IND）服务将事件通知实体。响应（RS）实体响应事件。确认（CF）服务通知实体响应。
Services may be confirmed, using the request, indication, response, and confirm primitives, or unconfirmed using just the request and indication primitives.
服务可以使用请求、指示、响应和确认原语进行确认，也可以仅使用请求和指示原语进行未确认。
ODETTE-FTP provides a number of security services to protect a Virtual File transmission across a hostile network.
ODETTE-FTP提供了许多安全服务来保护恶意网络中的虚拟文件传输。
These security services are as follows:
这些保安服务如下：
Confidentiality Integrity Non-repudiation of receipt Non-repudiation of origin Secure authentication
机密性完整性不可否认性收据不可否认性来源安全认证
Security services in this specification are implemented as follows:
本规范中的安全服务实现如下：
Session level encryption File level encryption Signed files Signed receipts Session level authentication ODETTE-FTP Authentication
会话级加密文件级加密签名文件签名收据会话级身份验证ODETE-FTP身份验证
Session level encryption provides data confidentiality by encryption of all the protocol commands and data exchanged between two parties, preventing a third party from extracting any useful information from the transmission.
会话级加密通过加密双方之间交换的所有协议命令和数据提供数据机密性，防止第三方从传输中提取任何有用信息。
This session level encryption is achieved by layering ODETTE-FTP over Transport Layer Security [TLS], distinguishing between secure and unsecure TCP/IP traffic using different port numbers.
此会话级加密是通过在传输层安全[TLS]上分层ODETE-FTP来实现的，使用不同的端口号区分安全和不安全的TCP/IP通信。
File encryption provides complementary data confidentiality by encryption of the files in their entirety. Generally, this encryption occurs prior to transmission, but it is also possible to encrypt and send files while in session. File encryption has the additional benefit of allowing a file to remain encrypted outside of the communications session in which it was sent. The file can be received and forwarded by multiple intermediaries, yet only the final destination will be able to decrypt the file. File encryption does not encrypt the actual protocol commands, so trading partner EDI codes and Virtual File names are still viewable.
文件加密通过对整个文件进行加密来提供补充数据机密性。通常，这种加密发生在传输之前，但也可以在会话中加密和发送文件。文件加密的另一个好处是允许文件在发送时的通信会话之外保持加密。该文件可以由多个中介接收和转发，但只有最终目的地才能解密该文件。文件加密不会加密实际的协议命令，因此贸易伙伴EDI代码和虚拟文件名仍然可见。
Secure authentication is implemented through the session level authentication features available in [TLS] and proves the identity of the parties wishing to communicate.
安全身份验证通过[TLS]中提供的会话级身份验证功能实现，并证明希望通信的各方的身份。
ODETTE-FTP Authentication also provides an authentication mechanism, but one that is integral to ODETTE-FTP and is available on all network infrastructures over which ODETTE-FTP is operated (this is in contrast to [TLS] which is generally only available over TCP/IP-based networks). Both parties are required to possess certificates when ODETTE-FTP Authentication is used.
ODETTE-FTP身份验证还提供了一种身份验证机制，但该机制是ODETTE-FTP的一个组成部分，可在所有运行ODETTE-FTP的网络基础设施上使用（这与[TLS]相反，后者通常仅在基于TCP/IP的网络上可用）。使用ODETE-FTP身份验证时，双方都必须拥有证书。
The security features in ODETTE-FTP 2 are centred around the use of [X.509] certificates. To take advantage of the complete range of security services offered in both directions, each party is required to possess an [X.509] certificate. If the confidentiality of data between two parties is the only concern, then [TLS] alone can be used, which allows the party accepting an incoming connection (the Responder) to be the only partner required to possess a certificate.
ODETTE-FTP 2中的安全功能主要围绕[X.509]证书的使用。为利用双向提供的全套安全服务，各方均需持有[X.509]证书。如果双方之间的数据保密性是唯一的问题，那么可以单独使用[TLS]，这允许接受传入连接的一方（响应方）成为拥有证书所需的唯一合作伙伴。
For businesses, this means that session level encryption between a hub and its trading partners can be achieved without requiring all the trading partners to obtain a certificate, assuming that trading partners always connect to the hub.
对于企业而言，这意味着可以实现集线器与其贸易伙伴之间的会话级加密，而无需所有贸易伙伴获得证书，前提是贸易伙伴始终连接到集线器。
With the exception of [TLS], all the security services work with X.25 and ISDN as transport media. Although nothing technically precludes [TLS] from working with X.25 or ISDN, implementations are rare.
除[TLS]外，所有安全服务都使用X.25和ISDN作为传输介质。虽然从技术上讲，没有任何东西可以阻止[TLS]使用X.25或ISDN，但实现很少。
ODETTE-FTP peer entities communicate with each other via the OSI Network Service or the Transmission Control Protocol Transport Service [RFC793]. This is described by service primitives representing request, indication, response, and confirmation actions.
ODETTE-FTP对等实体通过OSI网络服务或传输控制协议传输服务相互通信[RFC793]。这由表示请求、指示、响应和确认操作的服务原语描述。
For the Internet environment, the service primitives mentioned below for the Network Service have to be mapped to the respective Transport Service primitives. This section describes the Network Service primitives used by ODETTE-FTP and their relationship to the TCP interface. In practice, the local transport service application programming interface will be used to access the TCP service.
对于Internet环境，下面提到的用于网络服务的服务原语必须映射到相应的传输服务原语。本节介绍ODETTE-FTP使用的网络服务原语及其与TCP接口的关系。实际上，本地传输服务应用程序编程接口将用于访问TCP服务。
All network primitives can be directly mapped to the respective Transport primitives when using TCP.
使用TCP时，所有网络原语都可以直接映射到相应的传输原语。
N_CON_RQ ------> N_CON_IND
N_CON_CF <------ N_CON_RS
N_CON_RQ ------> N_CON_IND
N_CON_CF <------ N_CON_RS
This describes the setup of a connection. The requesting ODETTE-FTP peer uses the N_CON_RQ primitive to request an active OPEN of a connection to a peer ODETTE-FTP, the Responder, which has previously requested a passive OPEN. The Responder is notified of the incoming connection via N_CON_IND and accepts it with N_CON_RS. The requester is notified of the completion of its OPEN request upon receipt of N_CON_CF.
这描述了连接的设置。请求的ODETE-FTP对等方使用N_CON_RQ原语请求主动打开到对等ODETE-FTP的连接，该对等ODETE-FTP是先前请求被动打开的响应方。通过N_CON_IND通知响应者传入连接，并使用N_CON_RS接受连接。在收到N_CON_CF后，通知请求者其开放请求已完成。
Parameters
参数
Request Indication Response Confirmation
---------------------------------------------------------------------
Dest addr ------> same same same
Request Indication Response Confirmation
---------------------------------------------------------------------
Dest addr ------> same same same
N_DATA_RQ ------> N_DATA_IND
N_DATA_RQ ------> N_DATA_IND
Data exchange is an unconfirmed service. The requester passes data for transmission to the Network Service via the N_DATA_RQ primitive. The Responder is notified of the availability of data via N_DATA_IND.
数据交换是一项未经确认的服务。请求者通过N_data_RQ原语将要传输的数据传递给网络服务。通过N_data_IND通知响应者数据的可用性。
In practice, the notification and receipt of data may be combined, such as by the return from a blocking read from the network socket.
实际上，可以组合数据的通知和接收，例如通过从网络套接字读取的阻塞返回。
Parameters
参数
Request Indication
---------------------------------------------------------------------
Data ------------------> same
Request Indication
---------------------------------------------------------------------
Data ------------------> same
N_DISC_RQ ------> N_DISC_IND
N_DISC_RQ ------> N_DISC_IND
An ODETTE-FTP requests the termination of a connection with the N_DISC_RQ service primitive. Its peer is notified of the CLOSE by a N_DISC_IND event. It is recognised that each peer must issue a N_DISC_RQ primitive to complete the TCP symmetric close procedure.
ODETTE-FTP请求终止与N_DISC_RQ服务原语的连接。它的对等方被N_DISC_IND事件通知关闭。每个对等方都必须发出N_DISC_RQ原语以完成TCP对称关闭过程。
------> N_RST_IND
------> N_RST_IND
An ODETTE-FTP entity is notified of a network error by a N_RST_IND event. It should be noted that N_RST_IND would also be generated by a peer RESETTING the connection, but this is ignored here as N_RST_RQ is never sent to the Network Service by ODETTE-FTP.
网络错误由N_RST__IND事件通知ODETTE-FTP实体。应该注意的是，N_RST_IND也会由对等方重置连接生成，但这里忽略了这一点，因为N_RST_RQ从未通过ODETTE-FTP发送到网络服务。
[TLS] provides a mechanism for securing an ODETTE-FTP session over the Internet or a TCP network. ODETTE-FTP is layered over [TLS], distinguishing between secure and unsecure traffic by using different server ports.
[TLS]提供了一种通过Internet或TCP网络保护ODETTE-FTP会话的机制。ODETTE-FTP在[TLS]上分层，通过使用不同的服务器端口区分安全和不安全的通信量。
The implementation is very simple. Layer ODETTE-FTP over [TLS] in the same way as layering ODETTE-FTP over TCP/IP. [TLS] provides both session encryption and authentication, both of which may be used by the connecting parties. A party acts as a [TLS] server when receiving calls and acts as a [TLS] client when making calls. When the [TLS] handshake has completed, the responding ODETTE-FTP may start the ODETTE-FTP session by sending the Ready Message.
实现非常简单。[TLS]上的ODETTE-FTP分层方式与TCP/IP上的ODETTE-FTP分层方式相同。[TLS]提供会话加密和身份验证，连接方可以使用这两种功能。一方在接听电话时充当[TLS]服务器，在拨打电话时充当[TLS]客户端。[TLS]握手完成后，响应的ODETTE-FTP可通过发送就绪消息启动ODETTE-FTP会话。
An ODETTE-FTP requester will select a suitable local port.
ODETE-FTP请求程序将选择合适的本地端口。
The responding ODETTE-FTP will listen for connections on Registered Port 3305; the service name is 'odette-ftp'.
响应的ODETTE-FTP将侦听注册端口3305上的连接；服务名称为“odette ftp”。
The responding ODETTE-FTP will listen for secure TLS connections on Registered Port 6619; the service name is 'odette-ftps'.
响应的ODETTE-FTP将侦听注册端口6619上的安全TLS连接；服务名称为“odette ftps”。
The File Transfer Service describes the services offered by an ODETTE-FTP entity to its User Monitor (generally an application).
文件传输服务描述了ODETTE-FTP实体向其用户监视器（通常是应用程序）提供的服务。
NOTE: The implementation of the service primitives is an application issue.
注意：服务原语的实现是一个应用程序问题。
o-------------------o o-------------------o
| | | |
| USER MONITOR | | USER MONITOR |
| | | |
o-------------------o o-------------------o
| A | A
| | | |
F_XXX_RQ/RS | | F_XXX_IND/CF F_XXX_RQ/RS | | F_XXX_IND/CF
V | V |
o-------------------o o-------------------o
| |- - - - - - >| |
| ODETTE-FTP Entity | E-Buffer | ODETTE-FTP Entity |
| |< - - - - - -| |
o-------------------o o-------------------o
| A | A
N_XXX_RQ/RS | | N_XXX_IND/CF N_XXX_RQ/RS | | N_XXX_IND/CF
| | | |
V | V |
o---------------------------------------------------------o
| |
| N E T W O R K |
| |
o---------------------------------------------------------o
o-------------------o o-------------------o
| | | |
| USER MONITOR | | USER MONITOR |
| | | |
o-------------------o o-------------------o
| A | A
| | | |
F_XXX_RQ/RS | | F_XXX_IND/CF F_XXX_RQ/RS | | F_XXX_IND/CF
V | V |
o-------------------o o-------------------o
| |- - - - - - >| |
| ODETTE-FTP Entity | E-Buffer | ODETTE-FTP Entity |
| |< - - - - - -| |
o-------------------o o-------------------o
| A | A
N_XXX_RQ/RS | | N_XXX_IND/CF N_XXX_RQ/RS | | N_XXX_IND/CF
| | | |
V | V |
o---------------------------------------------------------o
| |
| N E T W O R K |
| |
o---------------------------------------------------------o
Key: E-Buffer - Exchange Buffer F_ - File Transfer Service Primitive N_ - Network Service Primitive
关键字：E-Buffer-Exchange Buffer F\文件传输服务原语N\网络服务原语
These diagrams represent the interactions between two communicating ODETTE-FTP entities and their respective User Agents.
这些图表示两个通信ODETTE-FTP实体及其各自用户代理之间的交互。
The vertical lines represent the ODETTE-FTP entities. The User Agents are not shown.
垂直线表示ODETTE-FTP实体。未显示用户代理。
| |
F_CONNECT_RQ ---->|------------|----> F_CONNECT_IND
| |
F_CONNECT_CF <----|------------|<---- F_CONNECT_RS
| |
| |
F_CONNECT_RQ ---->|------------|----> F_CONNECT_IND
| |
F_CONNECT_CF <----|------------|<---- F_CONNECT_RS
| |
Parameters
参数
Request Indication Response Confirm
---------------------------------------------------------------------
called-address -> same --- ----
calling-address-> same --- ----
ID1 ------------> same ID2 ------------> same
PSW1------------> same PSW2 -----------> same
mode1 ----------> mode2 ----------> mode3 ----------> same
restart1 -------> same -----------> restart2 -------> same
authentication1-> same -----------> authentication2-> same
---------------------------------------------------------------------
Request Indication Response Confirm
---------------------------------------------------------------------
called-address -> same --- ----
calling-address-> same --- ----
ID1 ------------> same ID2 ------------> same
PSW1------------> same PSW2 -----------> same
mode1 ----------> mode2 ----------> mode3 ----------> same
restart1 -------> same -----------> restart2 -------> same
authentication1-> same -----------> authentication2-> same
---------------------------------------------------------------------
Mode
模式
Specifies the file transfer capabilities of the entity sending or receiving a F_CONNECT primitive for the duration of the session.
指定在会话期间发送或接收F_CONNECT原语的实体的文件传输能力。
Value: Sender-only The entity can only send files. Receiver-only The entity can only receive files. Both The entity can both send and receive files.
值：仅发件人实体只能发送文件。仅接收器实体只能接收文件。实体可以发送和接收文件。
Negotiation: Sender-only Not negotiable. Receiver-only Not negotiable. Both Can be negotiated down to Sender-only or Receiver-only by the User Monitor or the ODETTE-FTP entity.
协商：仅发送方不可协商。只收不可转让。用户监视器或ODETTE-FTP实体可以将两者协商到“仅发送方”或“仅接收方”。
Request Indication Response Confirm
---------------------------------------------------------------------
Sender-only ----> Receiver-only --> Receiver-only --> Sender-only
Request Indication Response Confirm
---------------------------------------------------------------------
Sender-only ----> Receiver-only --> Receiver-only --> Sender-only
Receiver-only --> Sender-only ----> Sender-only ----> Receiver-only
Receiver-only --> Sender-only ----> Sender-only ----> Receiver-only
Both -----+-----> Both ----+------> Both -----------> Both
| or +------> Receiver-only --> Sender-only
| or +------> Sender-only ----> Receiver-only
|
or +-----> Receiver-only --> Receiver-only --> Sender-only
or +-----> Sender-only ----> Sender-only ----> Receiver-only
---------------------------------------------------------------------
Both -----+-----> Both ----+------> Both -----------> Both
| or +------> Receiver-only --> Sender-only
| or +------> Sender-only ----> Receiver-only
|
or +-----> Receiver-only --> Receiver-only --> Sender-only
or +-----> Sender-only ----> Sender-only ----> Receiver-only
---------------------------------------------------------------------
Restart
重新启动
Specifies the file transfer restart capabilities of the User Monitor.
指定用户监视器的文件传输重新启动功能。
Value: Y The entity can restart file transfers. N The entity cannot restart file transfers.
值：Y实体可以重新启动文件传输。N实体无法重新启动文件传输。
Negotiation:
谈判：
Request Indication Response Confirm
---------------------------------------------------------------------
restart = Y ----> restart = Y --+-> restart = Y ----> restart = Y
or +-> restart = N ----> restart = N
Request Indication Response Confirm
---------------------------------------------------------------------
restart = Y ----> restart = Y --+-> restart = Y ----> restart = Y
or +-> restart = N ----> restart = N
restart = N ----> restart = N ----> restart = N ----> restart = N
---------------------------------------------------------------------
restart = N ----> restart = N ----> restart = N ----> restart = N
---------------------------------------------------------------------
Authentication
认证
Specifies the authentication requirement of the User Monitor.
指定用户监视器的身份验证要求。
Value: Y Authentication required. N Authentication not required.
值：需要Y身份验证。N不需要身份验证。
Negotiation: Not negotiable.
谈判：不可谈判。
Request Indication Response Confirm
---------------------------------------------------------------------
auth = Y ----> auth = Y ----> auth = Y ----> auth = Y
Request Indication Response Confirm
---------------------------------------------------------------------
auth = Y ----> auth = Y ----> auth = Y ----> auth = Y
auth = N ----> auth = N ----> auth = N ----> auth = N
---------------------------------------------------------------------
auth = N ----> auth = N ----> auth = N ----> auth = N
---------------------------------------------------------------------
| |
F_START_FILE_RQ ---->|------------|----> F_START_FILE_IND
| |
F_START_FILE_CF(+|-) <----|------------|<---- F_START_FILE_RS(+|-)
| |
| |
F_START_FILE_RQ ---->|------------|----> F_START_FILE_IND
| |
F_START_FILE_CF(+|-) <----|------------|<---- F_START_FILE_RS(+|-)
| |
Parameters
参数
Request Ind. RS(+) CF(+) RS(-) CF(-)
------------------------------------------------------------------
filename-------> same ---- ---- ---- ----
date-time------> same ---- ---- ---- ----
destination----> same ---- ---- ---- ----
originator-----> same ---- ---- ---- ----
rec-format-----> same ---- ---- ---- ----
rec-size ------> same ---- ---- ---- ----
file-size------> same ---- ---- ---- ----
org-file-size--> same ---- ---- ---- ----
signed-eerp----> same ---- ---- ---- ----
cipher---------> same ---- ---- ---- ----
sec-services---> same ---- ---- ---- ----
compression----> same ---- ---- ---- ----
envelope-format> same ---- ---- ---- ----
description----> same ---- ---- ---- ----
restart-pos1---> same-> restart-pos2-> same ---- ----
---- ---- ---- ---- cause ------> same
---- ---- ---- ---- retry-later-> same
------------------------------------------------------------------
Request Ind. RS(+) CF(+) RS(-) CF(-)
------------------------------------------------------------------
filename-------> same ---- ---- ---- ----
date-time------> same ---- ---- ---- ----
destination----> same ---- ---- ---- ----
originator-----> same ---- ---- ---- ----
rec-format-----> same ---- ---- ---- ----
rec-size ------> same ---- ---- ---- ----
file-size------> same ---- ---- ---- ----
org-file-size--> same ---- ---- ---- ----
signed-eerp----> same ---- ---- ---- ----
cipher---------> same ---- ---- ---- ----
sec-services---> same ---- ---- ---- ----
compression----> same ---- ---- ---- ----
envelope-format> same ---- ---- ---- ----
description----> same ---- ---- ---- ----
restart-pos1---> same-> restart-pos2-> same ---- ----
---- ---- ---- ---- cause ------> same
---- ---- ---- ---- retry-later-> same
------------------------------------------------------------------
Notes:
笔记：
1. Retry-later has values "Y" or "N". 2. Cause is the reason for refusing the transfer (1,..,13,99). 3. Restart-pos1 not equal 0 is only valid if restart has been agreed during initial negotiation. 4. Restart-pos2 is less than or equal to restart-pos1.
1. 稍后重试的值为“Y”或“N”。2.原因是拒绝转让的原因（1，…，13,99）。3.Restart-pos1不等于0仅在初始协商期间同意重新启动时有效。4.Restart-pos2小于或等于Restart-pos1。
| |
F_DATA_RQ ---->|------------|----> F_DATA_IND
| |
F_DATA_CF <----|(---CDT----)|
| |
| |
F_DATA_RQ ---->|------------|----> F_DATA_IND
| |
F_DATA_CF <----|(---CDT----)|
| |
Note: Unlike other commands, where the F_XXX_CF signal is a result of a corresponding F_XXX_RS command, in this case, the local entity layer issues this signal when it is ready for the next data request. This decision is based on the current credit count and the reception of CDT (Set Credit) from the receiver.
注：与其他命令不同，F_XXX_CF信号是相应F_XXX_RS命令的结果，在这种情况下，本地实体层在准备好下一个数据请求时发出此信号。此决定基于当前信用计数和从接收方接收的CDT（设置信用）。
| |
F_CLOSE_FILE_RQ --->|------------|----> F_CLOSE_FILE_IND
| |
F_CLOSE_FILE_CF(+|-) <---|------------|<---- F_CLOSE_FILE_RS(+|-)
| |
| |
F_CLOSE_FILE_RQ --->|------------|----> F_CLOSE_FILE_IND
| |
F_CLOSE_FILE_CF(+|-) <---|------------|<---- F_CLOSE_FILE_RS(+|-)
| |
Parameters
参数
Request Ind RS(+) CF(+) RS(-) CF(-)
---------------------------------------------------------------------
rec-count ---> same ---- ---- ---- ----
unit-count --> same ---- ---- ---- ----
---- ---- Speaker=Y ---> Speaker=N ---- ----
---- ---- Speaker=N ---> Speaker=Y ---- ----
---- ---- ---- ---- cause ---> same
---------------------------------------------------------------------
Request Ind RS(+) CF(+) RS(-) CF(-)
---------------------------------------------------------------------
rec-count ---> same ---- ---- ---- ----
unit-count --> same ---- ---- ---- ----
---- ---- Speaker=Y ---> Speaker=N ---- ----
---- ---- Speaker=N ---> Speaker=Y ---- ----
---- ---- ---- ---- cause ---> same
---------------------------------------------------------------------
In a positive Close File response (F_CLOSE_FILE_RS(+)) the current Listener may either:
在正向关闭文件响应（F_Close_File_RS（+））中，当前侦听器可能：
1. Set Speaker to "Yes" and become the Speaker or 2. Set Speaker to "No" and remain the Listener.
1. 将演讲者设置为“是”，并成为演讲者或2。将演讲者设置为“否”，并保持听众身份。
The File Transfer service will ensure that the setting of the speaker parameter is consistent with the capabilities of the peer user.
文件传输服务将确保扬声器参数的设置与对等用户的能力一致。
The turn is never exchanged in the case of a negative response or confirmation.
如果是否定回答或确认，则不交换回合。
Only the Speaker is allowed to issue F_XXX_FILE_RQ primitives.
只允许演讲者发布F_XXX_FILE_RQ原语。
The Initiator becomes the first Speaker at the end of the Session Setup (F_CONNECT_CF received by Initiator and F_CONNECT_RS sent by Responder).
在会话设置结束时，发起者成为第一个发言者（发起者接收F_CONNECT_CF，响应者发送F_CONNECT_RS）。
Rules:
规则：
1. At each unsuccessful End of File, the turn is not exchanged.
1. 在文件的每一个不成功的结尾，回合不交换。
2. At each successful End of File, the turn is exchanged if requested by the Listener:
2. 在文件的每个成功结束时，如果侦听器请求，将交换回合：
- The current Listener receives F_CLOSE_FILE_IND (Speaker = choice).
- 当前侦听器接收F_CLOSE_FILE_IND（Speaker=choice）。
- If the Listener answers F_CLOSE_FILE_RS(Speaker = YES), it becomes the Speaker, the Speaker receives F_CLOSE_FILE_CF (Speaker = NO) and becomes the Listener.
- 如果听者回答F_CLOSE_FILE_RS（Speaker=YES），它将成为演讲者，演讲者将收到F_CLOSE_FILE_CF（Speaker=NO）并成为听者。
- If the Listener answers F_CLOSE_FILE_RS(Speaker = NO), it remains as the Listener, and the Speaker receives F_CLOSE_FILE_CF (Speaker = YES) and remains as the Speaker.
- 如果听者回答F_CLOSE_FILE_RS（Speaker=NO），它将保留为听者，而说话者将收到F_CLOSE_FILE_CF（Speaker=YES）并保留为说话者。
3. The Speaker can issue a Change Direction request (F_CD_RQ) to become the Listener. The Listener receives a Change Direction indication (F_CD_IND) and becomes the Speaker.
3. 演讲者可以发出改变方向请求（F_CD_RQ）成为听众。听者收到改变方向指示（F_CD_IND）并成为演讲者。
4. In order to prevent loops of F_CD_RQ/IND, the Speaker may not send an F_CD_RQ after receiving an unsolicited F_CD_IND. If the Listener receives a solicited F_CD_IND as a result of sending EFPA(Speaker=Yes), it is acceptable to immediately relinquish the right to speak by sending an F_CD_RQ.
4. 为了防止F_CD_RQ/IND循环，演讲者在收到未经请求的F_CD_RQ后不得发送F_CD_RQ。如果听者由于发送EFPA而收到请求的F_CD_IND（演讲者=是），则可以通过发送F_CD_RQ立即放弃发言权。
This service is initiated by the current Speaker (if there is no file transfer in progress) to send an End to End Response from the final destination to the originator of a file.
此服务由当前说话人启动（如果没有正在进行的文件传输），以从最终目的地向文件的发起人发送端到端响应。
| |
F_EERP_RQ ---->|------------|----> F_EERP_IND
| |
F_RTR_CF <----|------------|<---- F_RTR_RS
| |
| |
F_EERP_RQ ---->|------------|----> F_EERP_IND
| |
F_RTR_CF <----|------------|<---- F_RTR_RS
| |
Parameters
参数
Request Indication
------------------------------------
filename -----------> same
date ---------------> same
time ---------------> same
destination --------> same
originator ---------> same
hash ---------------> same
signature ----------> same
------------------------------------
Request Indication
------------------------------------
filename -----------> same
date ---------------> same
time ---------------> same
destination --------> same
originator ---------> same
hash ---------------> same
signature ----------> same
------------------------------------
Relationship with Turn:
与Turn的关系：
- Only the Speaker may send an End to End Response request.
- 只有演讲者可以发送端到端响应请求。
- Invoking the EERP service does not change the turn.
- 调用EERP服务不会改变回合。
- If an F_CD_IND has been received just before F_EERP_RQ is issued, this results in leaving the special condition created by the reception of F_CD_IND; i.e., while it was possible to issue F_RELEASE_RQ and not possible to issue F_CD_RQ just after the reception of F_CD_IND, after having issued F_EERP_RQ the normal Speaker status is entered again (F_CD_RQ valid, but F_RELEASE_RQ not valid).
- 如果F_CD_IND在F_EERP_RQ发布之前刚刚收到，这将导致留下F_CD_IND接收产生的特殊条件；i、 例如，虽然在收到F_CD_IND后可以发出F_RELEASE_RQ，但不可能发出F_CD_RQ，发出F_EERP_RQ后，再次进入正常扬声器状态（F_CD_RQ有效，但F_RELEASE_RQ无效）。
Notes:
笔记：
1. The F_EERP_RQ (and also F_NERP_RQ) is confirmed with an F_RTR_CF signal. The F_RTR_CF signal is common to both F_EERP_RQ and F_NERP_RQ. There should be no ambiguity, since there can only be one such request pending at any one time.
1. F_EERP_RQ（以及F_NERP_RQ）由F_RTR_CF信号确认。F_RTR_CF信号对于F_EERP_RQ和F_NERP_RQ都是通用的。不应该有歧义，因为在任何时候都只能有一个这样的请求等待处理。
2. The signature is optional and is requested when sending the F_START_FILE_RQ.
2. 签名是可选的，在发送F_START_文件_RQ时请求签名。
3. If it is not possible to sign the EERP, then an unsigned EERP should still be sent.
3. 如果无法对EERP进行签名，则仍应发送未签名的EERP。
4. It is an application implementation issue to validate the contents of the EERP and its signature and to decide what action to take on receipt of an EERP that fails validation or is not signed when a signed EERP was requested.
4. 这是一个应用程序实现问题，用于验证EERP及其签名的内容，并决定在收到未通过验证的EERP或在请求签名的EERP时未签名的EERP时应采取的措施。
This service is initiated by the current speaker (if there is no file transfer in progress) to send a Negative End Response when a file could not be transmitted to the next destination. It is sent only if the problem is of a non-temporary kind.
当文件无法传输到下一个目标时，此服务由当前扬声器启动（如果没有正在进行的文件传输），以发送否定结束响应。仅当问题属于非临时性问题时才会发送。
This service may also be initiated by the final destination instead of sending an End to End Response when a file could not be processed, after having successfully received the file.
当文件在成功接收后无法处理时，此服务也可以由最终目标启动，而不是发送端到端响应。
| |
F_NERP_RQ ---->|------------|----> F_NERP_IND
| |
F_RTR_CF <----|------------|----- F_RTR_RS
| |
| |
F_NERP_RQ ---->|------------|----> F_NERP_IND
| |
F_RTR_CF <----|------------|----- F_RTR_RS
| |
Parameters
参数
Request Indication
---------------------------------------------------
filename ----------------------> same
date --------------------------> same
time --------------------------> same
destination -------------------> same
originator --------------------> same
creator of negative response --> same
reason ------------------------> same
reason text -------------------> same
hash --------------------------> same
signature ---------------------> same
---------------------------------------------------
Request Indication
---------------------------------------------------
filename ----------------------> same
date --------------------------> same
time --------------------------> same
destination -------------------> same
originator --------------------> same
creator of negative response --> same
reason ------------------------> same
reason text -------------------> same
hash --------------------------> same
signature ---------------------> same
---------------------------------------------------
Relationship with Turn:
与Turn的关系：
The same as for the End-To-End response (see Section 3.3.5).
与端到端响应相同（见第3.3.5节）。
| |
F_RELEASE_RQ ---->|------------|----> F_RELEASE_IND
| |
| |
F_RELEASE_RQ ---->|------------|----> F_RELEASE_IND
| |
Parameters
参数
Request Indication
---------------------------------------------------------------------
reason = normal -------> ----
---------------------------------------------------------------------
Request Indication
---------------------------------------------------------------------
reason = normal -------> ----
---------------------------------------------------------------------
The Release service can only be initiated by the Speaker.
释放服务只能由扬声器启动。
The Speaker can only issue a Release request (F_RELEASE_RQ) just after receiving an unsolicited Change Direction indication (F_CD_IND). This ensures that the other partner doesn't want to send any more files in this session.
扬声器只能在收到未经请求的更改方向指示（F_CD_IND）后发出释放请求（F_Release_RQ）。这可确保其他合作伙伴不希望在此会话中发送更多文件。
Peer ODETTE-FTP entities action a normal session release by specifying Reason = Normal in an End Session (ESID) command.
对等ODETTE-FTP实体通过在结束会话（ESID）命令中指定REASURE=normal来操作正常会话释放。
| |
F_RELEASE_RQ ---->|------------|----> F_ABORT_IND
| |
| |
F_RELEASE_RQ ---->|------------|----> F_ABORT_IND
| |
Parameters
参数
Request Indication
---------------------------------------------------------------------
reason = error value --> same (or equivalent)
AO (Abort Origin) = (L)ocal or (D)istant
---------------------------------------------------------------------
Request Indication
---------------------------------------------------------------------
reason = error value --> same (or equivalent)
AO (Abort Origin) = (L)ocal or (D)istant
---------------------------------------------------------------------
Abnormal session release can be initiated by either the Speaker or the Listener and also by the user or provider.
异常会话释放可以由说话者或听话者发起，也可以由用户或提供者发起。
Abnormal session release can occur at any time within the session.
异常会话释放可以在会话内的任何时间发生。
Peer ODETTE-FTP entities action an abnormal session release by specifying Reason = Error-value in an End Session (ESID) command.
对等ODETTE-FTP实体通过在结束会话（ESID）命令中指定Reason=Error值来操作异常会话释放。
The abnormal session release deals with the following types of error:
异常会话释放处理以下类型的错误：
1. The service provider will initiate an abnormal release in the following cases:
1. 在以下情况下，服务提供商将启动异常释放：
1. Protocol error. 2. Failure of the Start Session (SSID) negotiation. 3. Command not recognised. 4. Data Exchange Buffer size error. 5. Resources not available. 6. Other unspecified abort code (with Reason = unspecified).
1. 协议错误。2.启动会话（SSID）协商失败。3.命令未被识别。4.数据交换缓冲区大小错误。5.没有可用的资源。6.其他未指定的中止代码（原因=未指定）。
2. The User Monitor will initiate an abnormal release in the following cases:
2. 在以下情况下，用户监视器将启动异常释放：
1. Local site emergency close down. 2. Resources not available. 3. Other unspecified abort code (with Reason = unspecified).
1. 现场紧急关闭。2.没有可用的资源。3.其他未指定的中止代码（原因=未指定）。
Other error types may be handled by an abort of the connection.
其他错误类型可以通过中断连接来处理。
| |
F_ABORT_RQ ---->|------------|----> F_ABORT_IND
| |
User-Initiated Abort
| |
F_ABORT_RQ ---->|------------|----> F_ABORT_IND
| |
User-Initiated Abort
| |
F_ABORT_IND <----|------------|----> F_ABORT_IND
| |
Provider-Initiated Abort
| |
F_ABORT_IND <----|------------|----> F_ABORT_IND
| |
Provider-Initiated Abort
Parameters
参数
Request Indication
---------------------------------------------------------------------
-- R (Reason): specified or unspecified
-- AO (Abort Origin): (L)ocal or (D)istant
---------------------------------------------------------------------
Request Indication
---------------------------------------------------------------------
-- R (Reason): specified or unspecified
-- AO (Abort Origin): (L)ocal or (D)istant
---------------------------------------------------------------------
The Abort service may be invoked by either entity at any time.
任何实体都可以随时调用中止服务。
The service provider may initiate an abort in case of error detection.
如果检测到错误，服务提供商可以启动中止。
User | OFTP | Network | OFTP | User
---------------|------|----------------------|------|---------------
| | | |
User | OFTP | Network | OFTP | User
---------------|------|----------------------|------|---------------
| | | |
1. Normal Release
1. 正常释放
F_RELEASE_RQ | | ESID(R=normal) | | F_RELEASE_IND
*--------------|-> ==|======================|=> --|-------------->
(R=normal) | | | |
F_RELEASE_RQ | | ESID(R=normal) | | F_RELEASE_IND
*--------------|-> ==|======================|=> --|-------------->
(R=normal) | | | |
2. User-Initiated Abnormal Release
2. 用户启动的异常释放
F_RELEASE_RQ | | ESID(R=error) | | F_ABORT_IND
*--------------|-> ==|======================|=> -|-------------->
(R=error value)| | | | (R=error,AO=D)
F_RELEASE_RQ | | ESID(R=error) | | F_ABORT_IND
*--------------|-> ==|======================|=> -|-------------->
(R=error value)| | | | (R=error,AO=D)
3. Provider-Initiated Abnormal Release
3. 提供程序启动了异常释放
F_ABORT_IND | | ESID(R=error) | | F_ABORT_IND
<--------------|-* *=|======================|=> --|-------------->
| | | |
F_ABORT_IND | | ESID(R=error) | | F_ABORT_IND
<--------------|-* *=|======================|=> --|-------------->
| | | |
4. User-Initiated Connection Abort
4. 用户启动的连接中止
F_ABORT_RQ | | N_DISC_RQ | | F_ABORT_IND
*--------------|-> --|--------->..----------|-> --|-------------->
| | N_DISC_IND | | (R=unsp.,AO=D)
F_ABORT_RQ | | N_DISC_RQ | | F_ABORT_IND
*--------------|-> --|--------->..----------|-> --|-------------->
| | N_DISC_IND | | (R=unsp.,AO=D)
5. Provider-Initiated Connection Abort
5. 提供程序启动的连接中止
F_ABORT_IND | | N_DISC_RQ | | F_ABORT_IND
<--------------|-* *-|--------->..----------|-> --|-------------->
(R=error,AO=L) | | N_DISC_IND | | (R=unsp.,AO=D)
F_ABORT_IND | | N_DISC_RQ | | F_ABORT_IND
<--------------|-* *-|--------->..----------|-> --|-------------->
(R=error,AO=L) | | N_DISC_IND | | (R=unsp.,AO=D)
Key: * Origin of command flow
F_ ---> File Transfer Service primitive
N_ ---> Network Service primitive
===> ODETTE-FTP (OFTP) protocol message
Key: * Origin of command flow
F_ ---> File Transfer Service primitive
N_ ---> Network Service primitive
===> ODETTE-FTP (OFTP) protocol message
These state automata define the service as viewed by the User Monitor. Events causing a state transition are shown in lower case and the resulting action in upper case where appropriate.
这些状态自动机定义用户监视器查看的服务。导致状态转换的事件以小写形式显示，相应的结果操作以大写形式显示。
o------------o
decision | | f_connect_ind
+-----------------| IDLE |-----------------+
| F_CONNECT_RQ | (0) | F_CONNECT_RS |
| o------------o |
V |
o-----------------o |
| | |
| I_WF_FCONNECTCF | |
| | |
o--------+--------o |
| |
| F_CONNECT_CF |
V V
o-----------------o o-----------------o
| | | |
| IDLE SPEAKER | | IDLE LISTENER |
| (1) | | (2) |
| See Speaker | | See Listener |
| State Diagram | | State Diagram |
| | | |
o-----------------o o-----------------o
o------------o
decision | | f_connect_ind
+-----------------| IDLE |-----------------+
| F_CONNECT_RQ | (0) | F_CONNECT_RS |
| o------------o |
V |
o-----------------o |
| | |
| I_WF_FCONNECTCF | |
| | |
o--------+--------o |
| |
| F_CONNECT_CF |
V V
o-----------------o o-----------------o
| | | |
| IDLE SPEAKER | | IDLE LISTENER |
| (1) | | (2) |
| See Speaker | | See Listener |
| State Diagram | | State Diagram |
| | | |
o-----------------o o-----------------o
o-----------------o o-----------------o
| IDLE LISTENER | | IDLE |
| CD_RQ just sent | | see (0) |
| see (3), Listen | | Idle |
| State Diagram | | State Diagram |
o-----------------o o-----------------o
A A
| |
decision decision
F_CD_RQ F_RELEASE_RQ
| |
o================o decision o----------o decision o---------------o
| |---------->| WAIT FOR |<----------| |
| | F_EERP_RQ | | F_EERP_RQ | |
| IDLE | | EERP/ | | IDLE |
| SPEAKER | decision | NERP | decision | SPEAKER |
| (1) |---------->| CONFIRM. |<----------| (4) |
| | F_NERP_RQ | | F_NERP_RQ | |
| | | | | |
| | | | | CD_IND |
| | f_rtr_cf | | | just received |
| |<----------| | | |
| | o----------o | |
| | | |
| | | |
o================o o---------------o
A A | |
| | | decision and P2 decision and P2 |
| | +-----------------+ +---------------------+
| | F_START_FILE_RQ | | F_START_FILE_RQ
| | V V
| | o---------------o
| | f_file_start_cf(-) | |
| +----------------------| OPENING |
| | |
| o---------------o
| |
f_file_close_cf(-) or f_start_file_cf(+)
f_file_close_cf(+) and not P1 |
| V
o-----------------o o-----------------o
| IDLE LISTENER | | IDLE |
| CD_RQ just sent | | see (0) |
| see (3), Listen | | Idle |
| State Diagram | | State Diagram |
o-----------------o o-----------------o
A A
| |
decision decision
F_CD_RQ F_RELEASE_RQ
| |
o================o decision o----------o decision o---------------o
| |---------->| WAIT FOR |<----------| |
| | F_EERP_RQ | | F_EERP_RQ | |
| IDLE | | EERP/ | | IDLE |
| SPEAKER | decision | NERP | decision | SPEAKER |
| (1) |---------->| CONFIRM. |<----------| (4) |
| | F_NERP_RQ | | F_NERP_RQ | |
| | | | | |
| | | | | CD_IND |
| | f_rtr_cf | | | just received |
| |<----------| | | |
| | o----------o | |
| | | |
| | | |
o================o o---------------o
A A | |
| | | decision and P2 decision and P2 |
| | +-----------------+ +---------------------+
| | F_START_FILE_RQ | | F_START_FILE_RQ
| | V V
| | o---------------o
| | f_file_start_cf(-) | |
| +----------------------| OPENING |
| | |
| o---------------o
| |
f_file_close_cf(-) or f_start_file_cf(+)
f_file_close_cf(+) and not P1 |
| V
o---------------o o---------------o record to send o---------o
| | | |------------------>| |
| CLOSING | | DATA TRANSFER | F_DATA_RQ | NEXT |
| | | | | RECORD |
| | | | f_data_cf | |
| | | |<------------------| |
o---------------o o---------------o o---------o
| A |
| | end of file |
| +-------------------+
| F_CLOSE_FILE_RQ
| o-----------------o
| f_file_close_cf(+) and P1 | IDLE LISTENER |
+--------------------------------------------->| see (2), Listen |
| State Diagram |
Predicates: o-----------------o
P1: Positive confirmation and Speaker = YES
P2: Mode = Both or (Mode = Sender-only)
o---------------o o---------------o record to send o---------o
| | | |------------------>| |
| CLOSING | | DATA TRANSFER | F_DATA_RQ | NEXT |
| | | | | RECORD |
| | | | f_data_cf | |
| | | |<------------------| |
o---------------o o---------------o o---------o
| A |
| | end of file |
| +-------------------+
| F_CLOSE_FILE_RQ
| o-----------------o
| f_file_close_cf(+) and P1 | IDLE LISTENER |
+--------------------------------------------->| see (2), Listen |
| State Diagram |
Predicates: o-----------------o
P1: Positive confirmation and Speaker = YES
P2: Mode = Both or (Mode = Sender-only)
o-----------------o o-----------------o
| IDLE SPEAKER | | IDLE |
| CD_IND just | | |
| received see(4) | | see (0) |
| Speaker State | | Idle |
| Diagram | | State Diagram |
o-----------------o o-----------------o
A A
| |
decision f_eerp_ind decision
F_CD_IND +--------------+ F_RELEASE_IND
| | F_RTR_RS | |
o=================o | o-----------------o
| |<-----------+ | |
| | | |
| | f_nerp_ind | |
| |------------+ | |
| | F_RTR_RS | | |
| | | | |
| |<-----------+ | |
| IDLE LISTENER | f_eerp_ind | IDLE LISTENER |
| (2) |<-----------------------------| (3) |
| | F_RTR_RS | CD_RQ |
| | | just sent |
| | f_nerp_ind | |
| |<-----------------------------| |
o-----------------o o-----------------o
| IDLE SPEAKER | | IDLE |
| CD_IND just | | |
| received see(4) | | see (0) |
| Speaker State | | Idle |
| Diagram | | State Diagram |
o-----------------o o-----------------o
A A
| |
decision f_eerp_ind decision
F_CD_IND +--------------+ F_RELEASE_IND
| | F_RTR_RS | |
o=================o | o-----------------o
| |<-----------+ | |
| | | |
| | f_nerp_ind | |
| |------------+ | |
| | F_RTR_RS | | |
| | | | |
| |<-----------+ | |
| IDLE LISTENER | f_eerp_ind | IDLE LISTENER |
| (2) |<-----------------------------| (3) |
| | F_RTR_RS | CD_RQ |
| | | just sent |
| | f_nerp_ind | |
| |<-----------------------------| |
| | F_RTR_RS | |
| | | |
| | f_start_file_ind | |
| | and not P1 | |
| |---------------------+ | |
o=================o F_START_FILE_RS(-) | o-----------------o
A A | A A | | |
| | | | +-----------------------+ | |
| | | | | |
| | | | f_start_file_ind and not P1 | |
| | | +--------------------------------------+ |
| | | F_START_FILE_RS(-) |
| | | |
| | | f_start_file_ind f_start_file_ind |
| | | and P1 and P1 |
| | +----------------------------+ +------------------+
| | F_START_FILE_RS(+) | | F_START_FILE_RS(+)
| | V V
| | o---------------o
| |f_close_file_ind and not P3 | |
| +----------------------------| |
| F_CLOSE_FILE_RS(+,N) | |
| | DATA |
| | TRANSFER |
| f_close_file_ind and not P2 | |-------------+
+------------------------------| | |
F_CLOSE_FILE_RS(-) | |<------------+
o---------------o F_DATA_IND
o---------------o |
| IDLESPEAKER | f_close_file_ind and P3 |
| see (1), Spkr |<--------------------------+
| State Diagram | F_CLOSE_FILE_RS(+,Y)
o---------------o
| | F_RTR_RS | |
| | | |
| | f_start_file_ind | |
| | and not P1 | |
| |---------------------+ | |
o=================o F_START_FILE_RS(-) | o-----------------o
A A | A A | | |
| | | | +-----------------------+ | |
| | | | | |
| | | | f_start_file_ind and not P1 | |
| | | +--------------------------------------+ |
| | | F_START_FILE_RS(-) |
| | | |
| | | f_start_file_ind f_start_file_ind |
| | | and P1 and P1 |
| | +----------------------------+ +------------------+
| | F_START_FILE_RS(+) | | F_START_FILE_RS(+)
| | V V
| | o---------------o
| |f_close_file_ind and not P3 | |
| +----------------------------| |
| F_CLOSE_FILE_RS(+,N) | |
| | DATA |
| | TRANSFER |
| f_close_file_ind and not P2 | |-------------+
+------------------------------| | |
F_CLOSE_FILE_RS(-) | |<------------+
o---------------o F_DATA_IND
o---------------o |
| IDLESPEAKER | f_close_file_ind and P3 |
| see (1), Spkr |<--------------------------+
| State Diagram | F_CLOSE_FILE_RS(+,Y)
o---------------o
Predicates:
P1: Decision to send F_START_FILE_RS(+)
P2: Decision to send F_CLOSE_FILE_RS(+)
P3: Decision to become Speaker
Predicates:
P1: Decision to send F_START_FILE_RS(+)
P2: Decision to send F_CLOSE_FILE_RS(+)
P3: Decision to become Speaker
ODETTE-FTP is divided into five operating phases.
ODETTE-FTP分为五个操作阶段。
Start Session Start File Data Transfer End File End Session
开始会话开始文件数据传输结束文件结束会话
After the End File phase, an ODETTE-FTP entity may enter a new Start File phase or terminate the session via the End Session phase.
在结束文件阶段之后，ODETTE-FTP实体可以进入新的开始文件阶段或通过结束会话阶段终止会话。
ODETTE-FTP peers communicate by sending and receiving messages in Exchange Buffers via the Network Service. Each Exchange Buffer contains one of the following commands.
ODETTE-FTP对等方通过网络服务在Exchange缓冲区中发送和接收消息进行通信。每个Exchange缓冲区包含以下命令之一。
SSRM Start Session Ready Message SSID Start Session SECD Security Change Direction AUCH Authentication Challenge AURP Authentication Response SFID Start File SFPA Start File Positive Answer SFNA Start File Negative Answer DATA Data CDT Set Credit EFID End File EFPA End File Positive Answer EFNA End File Negative Answer ESID End Session CD Change Direction EERP End to End Response NERP Negative End Response RTR Ready To Receive
SSRM开始会话就绪消息SSID开始会话SECD安全更改方向AUCH身份验证挑战AURP身份验证响应SFID开始文件SFPA开始文件肯定应答SFNA开始文件否定应答数据CDT设置信用EFID结束文件EFPA结束文件肯定应答EFNA结束文件否定应答ESID结束会话CD更改方向EERP端到端响应NERP负端响应RTR准备接收
The remainder of this section describes the protocol flows. Section five details the command formats.
本节的其余部分描述协议流。第五节详细介绍了命令格式。
The Start Session phase is entered immediately after the network connection has been established.
网络连接建立后，立即进入启动会话阶段。
The ODETTE-FTP entity that took the initiative to establish the network connection becomes the Initiator. Its peer becomes the Responder.
主动建立网络连接的ODETTE-FTP实体成为发起方。它的同伴成为响应者。
The first message must be sent by the Responder.
第一条消息必须由响应者发送。
1. Initiator <-------------SSRM -- Responder Ready Message -- SSID ------------> Identification <------------ SSID -- Identification
1. 发起者<-----------SSRM--响应者就绪消息--SSID------>标识<-----------SSID--标识
Having exchanged SSIDs, the Initiator may optionally begin an authentication phase, in which each party proves its identity to the other.
交换SSID后，发起方可以选择性地开始身份验证阶段，其中各方向另一方证明其身份。
The first authentication message must be sent by the Initiator.
第一条身份验证消息必须由启动器发送。
1. Initiator -- SECD ------------> Responder Change Direction <------------ AUCH -- Challenge -- AURP ------------> Response <------------ SECD -- Change Direction -- AUCH ------------> Challenge <------------ AURP -- Response
1. 发起者--SECD-------->响应者更改方向--<-------------AUCH--Challenge--AURP-------->响应--SECD--Change Direction--AUCH-------->挑战--AURP--Response
The Initiator sends a Security Change Direction (SECD) to which the Responder replies with an Authentication Challenge (AUCH).
发起方发送安全更改方向（SECD），响应方用身份验证质询（AUCH）对其进行回复。
The Responder looks up the public certificate that is linked to the purported identity of the Initiator (located in the SSID). If the Responder is unable to locate a suitable certificate then authentication fails. The Responder uses the public key contained in the certificate to encrypt a random challenge, unique for each session, for the Initiator. This encrypted challenge is sent as a [CMS] envelope to the Initiator as part of the AUCH.
响应者查找链接到发起者的声称身份（位于SSID中）的公共证书。如果响应者无法找到合适的证书，则身份验证失败。响应者使用证书中包含的公钥加密启动器的随机质询，该质询对于每个会话都是唯一的。该加密质询作为[CMS]信封发送给发起人，作为AUCH的一部分。
The Initiator decrypts the challenge using their private key and sends the decrypted challenge back to the Responder in the Authentication Response (AURP).
发起方使用其私钥解密质询，并在身份验证响应（AURP）中将解密的质询发送回响应方。
The Responder checks that the data received in the AURP matches the random challenge that was sent to the Initiator.
响应者检查在AURP中接收的数据是否与发送给发起方的随机质询匹配。
If the data matches, then the Initiator has authenticated successfully and the Responder replies with a Security Change Direction (SECD) beginning the complementary process of verifying the Responder to the Initiator. If the data does not match, then the Initiator fails authentication.
如果数据匹配，则发起方已成功进行身份验证，响应方回复安全更改方向（SECD），开始向发起方验证响应方的补充过程。如果数据不匹配，则启动器验证失败。
The Initiator from the Start Session phase is designated the Speaker while the Responder becomes the Listener. The roles are reversed by the Speaker sending a Change Direction command to the Listener.
启动会话阶段的发起者被指定为演讲者，而响应者则成为听者。演讲者向听者发送一个改变方向的命令，角色就颠倒了。
1. Speaker -- SFID ------------> Listener Start File <------------ SFPA -- Answer YES
1. 演讲者--SFID------>监听器开始文件<-----------SFPA--回答是
2. Speaker -- SFID ------------> Listener Start File <------------ SFNA -- Answer NO Go To 1
2. 演讲者--SFID------>监听器开始文件<-----------SFNA--回答否转到1
Note: The User Monitor should take steps to prevent a loop situation occurring.
注意：用户监视器应采取措施防止循环情况发生。
2. Speaker -- CD --------------> Listener Change Direction Listener <------------ EERP -- Speaker End to End Response -- RTR -------------> Ready to Receive <------------ NERP -- Negative End Response -- RTR -------------> Ready to Receive <------------ SFID -- Start File
2. 扬声器--CD-------->侦听器更改方向侦听器--EERP--扬声器端到端响应--RTR-------->准备接收--NERP--负端响应--RTR-------->准备接收--SFID--开始文件
The Start File command includes a count allowing the restart of an interrupted transmission to be negotiated. If restart facilities are not available, the restart count must be set to zero. The sender will start with the lowest record count + 1.
Start File命令包括允许协商中断传输的重启的计数。如果重新启动设施不可用，则重新启动计数必须设置为零。发件人将以最低记录计数+1开始。
The destination in a Start File command can be specified as follows.
“开始文件”命令中的目标可以指定如下。
1. An explicitly defined destination.
1. 明确定义的目的地。
2. A group destination that allows an intermediate location to broadcast the Virtual File to multiple destinations.
2. 一种组目的地，允许中间位置将虚拟文件广播到多个目的地。
The Listener will send a negative answer to the Speaker when the destination is not known.
当目的地未知时，听者将向说话者发送否定回答。
The prioritisation of files for transmission is left to the local implementation. To allow some flexibility, a change direction mechanism is available in the End File phase.
要传输的文件的优先级由本地实施决定。为了允许一定的灵活性，在结束文件阶段可以使用更改方向机制。
The End to End Response (EERP) command notifies the originator of a Virtual File that the Virtual File has been successfully delivered to its final destination. This allows the originator to perform house keeping tasks such as deleting copies of the delivered data.
端到端响应（EERP）命令通知虚拟文件的发起人该虚拟文件已成功传递到其最终目标。这允许发起人执行内部管理任务，例如删除已交付数据的副本。
If the originator of the Virtual File requested a signed EERP in the SFID, the EERP must be signed. Signing allows the originator of the file to prove that the EERP was generated by the final destination. If the final destination is unable to sign the EERP, it may send back an unsigned EERP. It is an implementation issue to allow the acceptance of an unsigned EERP if a signed EERP is requested.
如果虚拟文件的发起人在SFID中请求签名的EERP，则必须对EERP进行签名。签名允许文件的发起人证明EERP是由最终目的地生成的。如果最终目的地无法签署EERP，则可能会发回未签署的EERP。如果请求签署的EERP，则允许接受未签署的EERP是一个实施问题。
A Response Command must be sent from the location performing the final processing or distribution of the data to the originator. The Response is mandatory and may be sent in the same or in any subsequent session.
必须从执行数据最终处理或分发的位置向发起人发送响应命令。响应是强制性的，可以在同一会话或任何后续会话中发送。
When an intermediate location broadcasts or distributes a Virtual File, it must receive a Response command from all the locations to which it forwarded the data before sending its own Response. This ensures that the Response received by the Virtual File's originator accounts for all the destination locations. An intermediate location therefore needs to track the status of files it processes over time.
当中间位置广播或分发虚拟文件时，在发送自己的响应之前，它必须从所有转发数据的位置接收响应命令。这确保了虚拟文件的发起人接收到的响应包含所有目标位置。因此，中间位置需要跟踪它随时间处理的文件的状态。
The requesting of a signed EERP is incompatible with the use of broadcast facilities because an EERP can be signed by only one destination. If this scenario occurs, the intermediate broadcast location may continue and ignore the request for a signed EERP or send back a NERP.
由于EERP只能由一个目的地签名，因此请求签名EERP与使用广播设施不兼容。如果出现这种情况，中间广播位置可能会继续并忽略对已签名EERP的请求或发回NERP。
Example: Point to Point
示例：点对点
Location A sends file Ba to location B, which will send an EERP to location A after it successfully receives the file.
位置A将文件Ba发送到位置B，位置B在成功接收文件后将向位置A发送EERP。
o----------o o-----------o
| Loc. A |----------- S1 ---------->| Loc. B |
| | | |
| [Ba] |<---------- R2 -----------| [Ba] |
+----------o o-----------o
o----------o o-----------o
| Loc. A |----------- S1 ---------->| Loc. B |
| | | |
| [Ba] |<---------- R2 -----------| [Ba] |
+----------o o-----------o
Key: S - File Transfer R - Response EERP [Ba] - File for B from A
键：S-文件传输R-响应EERP[Ba]-来自A的B文件
Example: Data distribution
示例：数据分发
Location A sends a Virtual File containing data for distribution to locations B and C via clearing centres E1 and E2. Clearing centre E1 must wait for a response from E2 (for file Ba) and location C before it sends its response, R8, to location A. Clearing centre E2 can only send response R7 to E1 when location B acknowledges file Ba with response R6.
位置A通过清算中心E1和E2将包含数据的虚拟文件发送到位置B和C。清算中心E1必须等待E2（对于文件Ba）和位置C的响应，然后才能将其响应R8发送到位置a。当位置B确认文件Ba具有响应R6时，清算中心E2只能将响应R7发送到E1。
o---------o o---------o o---------o o---------o
| Loc. A |-- S1 ->| Loc. E1 |-- S2 ->| Loc. E2 |-- S5 ->| Loc. B |
| | | | | | | |
| [Ba,Ca] |<- R8 --| [Ba,Ca] |<- R7 --| [Ba] |<- R6 --| [Ba] |
o---------o o---------o o---------o o---------o
A |
| | o---------o
| +----- S3 ->| Loc. C |
| | |
+--------- R4 --| [Ca] |
o---------o
o---------o o---------o o---------o o---------o
| Loc. A |-- S1 ->| Loc. E1 |-- S2 ->| Loc. E2 |-- S5 ->| Loc. B |
| | | | | | | |
| [Ba,Ca] |<- R8 --| [Ba,Ca] |<- R7 --| [Ba] |<- R6 --| [Ba] |
o---------o o---------o o---------o o---------o
A |
| | o---------o
| +----- S3 ->| Loc. C |
| | |
+--------- R4 --| [Ca] |
o---------o
Example: Data collection
示例：数据收集
Locations A and B send files Ca and Cb to clearing centre E1, which forwards both files to location C in a single Virtual File. When it receives response R4 from C, clearing centre E1 sends response R5 to location A and R6 to location B.
位置A和B将文件Ca和Cb发送到清算中心E1，清算中心E1在单个虚拟文件中将两个文件转发到位置C。当接收到来自C的响应R4时，清算中心E1将响应R5发送到位置A，将响应R6发送到位置B。
o---------o o---------o o---------o
| Loc. A |-- S1 ->| Loc. E1 |-- S3 ->| Loc. C |
| | | | | |
| [Ca] |<- R5 --| [Ca,Cb] |<- R4 --| [Ca,Cb] |
o---------o o---------o o---------o
A |
o---------o | |
| Loc. B |-- S2 -----+ |
| | |
| [Cb] |<- R6 ---------+
o---------o
o---------o o---------o o---------o
| Loc. A |-- S1 ->| Loc. E1 |-- S3 ->| Loc. C |
| | | | | |
| [Ca] |<- R5 --| [Ca,Cb] |<- R4 --| [Ca,Cb] |
o---------o o---------o o---------o
A |
o---------o | |
| Loc. B |-- S2 -----+ |
| | |
| [Cb] |<- R6 ---------+
o---------o
In addition to the EERP, which allows control over successful transmission of a file, a Negative End Response signals that a file could not be delivered to the final destination or that the final destination could not process the received file.
除了允许控制文件成功传输的EERP之外，负端响应还表示文件无法发送到最终目的地或最终目的地无法处理接收到的文件。
It may be created by an intermediate node that could not transmit the file any further because the next node refuses to accept the file. The cause of the refusal has to be non-temporary, otherwise the intermediate node has to try the transmission again.
它可能是由中间节点创建的，因为下一个节点拒绝接受该文件，所以无法进一步传输该文件。拒绝的原因必须是非临时的，否则中间节点必须再次尝试传输。
It may also be created by the final node that is unable to process the file because of non-recoverable syntax or semantic errors in the file, or because of the failure of any other processing performed on the file.
由于文件中存在不可恢复的语法或语义错误，或者由于对文件执行的任何其他处理失败，最终节点也可能无法处理该文件。
The NERP will be sent back to the originator of the file.
NERP将发送回文件的发起人。
The parameters are equal to the ones of the EERP, but with additional information about the creator of the NERP and the abort reason. Where the NERP is created due to a failure to transmit, the abort reason is taken from the refusal reason that was sent by the node refusing the file. Because of the NERP, it is possible for the intermediate node to stop trying to send the non-deliverable file and to delete the file.
这些参数与EERP的参数相同，但包含有关NERP创建者和中止原因的附加信息。如果由于传输失败而创建NERP，则中止原因取自拒绝文件的节点发送的拒绝原因。由于NERP，中间节点可能停止尝试发送不可交付文件并删除该文件。
The NERP allows the originator of the file to react to the unsuccessful transmission or processing, depending on the reason code and the creator of the NERP.
NERP允许文件的发起人对不成功的传输或处理做出反应，具体取决于原因代码和NERP的创建者。
If the originator of the Virtual File requested a signed EERP in the SFID, the NERP must be signed. Signing allows the originator of the file to prove by whom the NERP was generated. If the location
如果虚拟文件的发起人在SFID中请求签名的EERP，则必须对NERP进行签名。签名允许文件的发起人证明NERP是由谁生成的。如果地点
generating the NERP is unable to sign the NERP, it may send back an unsigned NERP. It is an implementation issue to allow the acceptance of an unsigned EERP if a signed NERP is requested.
生成NERP无法对NERP签名，它可能会发回未签名的NERP。如果请求签署的NERP，允许接受未签署的EERP是一个实施问题。
In order to avoid congestion between two adjacent nodes caused by a continuous flow of EERPs and NERPs, a Ready To Receive (RTR) command is provided. The RTR acts as an EERP/NERP acknowledgement for flow control but has no end-to-end significance.
为了避免EERP和NERP的连续流导致两个相邻节点之间的拥塞，提供了一个准备接收（RTR）命令。RTR作为EERP/NERP流量控制确认，但没有端到端意义。
Speaker -- EERP ------------> Listener End to End Response
<------------- RTR -- Ready to Receive
-- EERP ------------> End to End Response
<------------- RTR -- Ready to Receive
-- NERP ------------> Negative End Response
<------------- RTR -- Ready to Receive
-- SFID ------------> Start File
or
-- CD --------------> Exchange the turn
Speaker -- EERP ------------> Listener End to End Response
<------------- RTR -- Ready to Receive
-- EERP ------------> End to End Response
<------------- RTR -- Ready to Receive
-- NERP ------------> Negative End Response
<------------- RTR -- Ready to Receive
-- SFID ------------> Start File
or
-- CD --------------> Exchange the turn
After sending an EERP or NERP, the Speaker must wait for an RTR before sending any other commands. The only acceptable commands to follow are:
在发送EERP或NERP后，扬声器在发送任何其他命令之前必须等待RTR。以下是唯一可接受的命令：
EERP NERP SFID or CD (if there are no more EERPs or NERPs to be sent)
EERP NERP SFID或CD（如果不再发送EERP或NERP）
Virtual File data flows from the Speaker to the Listener during the Data Transfer phase, which is entered after the Start File phase.
虚拟文件数据在数据传输阶段从说话人流向听话人，该阶段在开始文件阶段之后输入。
To avoid congestion at the protocol level, a flow control mechanism is provided via the Set Credit (CDT) command.
为了避免协议级别的拥塞，通过Set Credit（CDT）命令提供了流控制机制。
A Credit limit is negotiated in the Start Session phase; this represents the number of Data Exchange Buffers that the Speaker may send before it is obliged to wait for a Credit command from the Listener.
在启动会话阶段协商信用额度；这表示演讲者在被迫等待来自听者的信用命令之前可能发送的数据交换缓冲区的数量。
The available credit is initially set to the negotiated value by the Start File positive answer, which acts as an implicit Credit command. The Speaker decreases the available credit count by one for each data buffer sent to the Listener.
可用信用最初由启动文件肯定应答设置为协商值，该应答充当隐式信用命令。对于发送给侦听器的每个数据缓冲区，扬声器将可用信用计数减少一。
When the available credit is exhausted, the Speaker must wait for a Credit command from the Listener; otherwise, a protocol error will occur and the session will be aborted.
当可用信用耗尽时，演讲者必须等待听者发出信用命令；否则，将发生协议错误，会话将中止。
The Listener should endeavour to send the Credit command without delay to prevent the Speaker blocking.
听者应尽力毫不延迟地发送信用命令，以防止说话者阻塞。
1. Speaker -- SFID ------------> Listener Start File <------------ SFPA -- Answer YES
1. 演讲者--SFID------>监听器开始文件<-----------SFPA--回答是
2. If the credit value is set to 2
2. 如果信用值设置为2
Speaker -- Data ------------> Listener Start File
-- Data ------------>
<------------- CDT -- Set Credit
-- Data ------------>
-- EFID ------------> End File
Speaker -- Data ------------> Listener Start File
-- Data ------------>
<------------- CDT -- Set Credit
-- Data ------------>
-- EFID ------------> End File
The Speaker notifies the Listener that it has finished sending a Virtual File by sending an End File (EFID) command. The Listener replies with a positive or negative End File command and has the option to request a Change Direction command from the Speaker.
扬声器通过发送结束文件（EFID）命令通知侦听器它已完成发送虚拟文件。侦听器使用肯定或否定的结束文件命令进行回复，并可以选择请求扬声器发出更改方向命令。
1. Speaker -- EFID ------------> Listener End File <------------ EFPA -- Answer YES
1. 演讲者--EFID------>监听器结束文件<-----------EFPA--回答是
2. Speaker -- EFID ------------> Listener End File <------------ EFPA -- Answer YES + CD -- CD --------------> Change Direction Listener <------------ EERP -- Speaker End to End Response -------------- RTR -> Ready to Receive Listener <------------ NERP -- Speaker Negative End Response -------------- RTR -> Ready to Receive Go to Start File Phase
2. 扬声器--EFID-------->侦听器结束文件--EFPA--回答是+CD--CD-------->更改方向侦听器--EERP--扬声器端到端响应--RTR->准备接收侦听器--NERP--扬声器负端响应--RTR->准备接收转到开始文件阶段
3. Speaker -- EFID ------------> Listener End File <------------ EFNA -- Answer NO
3. 说话人--EFID------>侦听器结束文件<-------EFNA--回答否
The Speaker terminates the session by sending an End Session (ESID) command. The Speaker may only do this if the Listener has just relinquished its role as speaker.
演讲者通过发送结束会话（ESID）命令来终止会话。演讲者只有在听者刚刚放弃演讲者的角色时才能这样做。
1. Speaker -- EFID ------------> Listener End File <------------ EFPA -- Answer YES -- CD --------------> Change Direction Listener <------------ ESID -- Speaker End Session
1. 演讲者--EFID-------->侦听器结束文件--EFPA--回答是--CD-------->更改方向侦听器--ESID--演讲者结束会话
Error detection and handling should be done as close as possible to the problem. This aids problem determination and correction. Each layer of the reference model is responsible for its own error handling.
错误检测和处理应尽可能靠近问题。这有助于确定和纠正问题。参考模型的每一层都负责自己的错误处理。
ODETTE-FTP can detect protocol errors by virtue of its state machine and uses activity timers to detect session hang conditions. These mechanisms are separate from the End to End controls.
ODETTE-FTP可以借助其状态机检测协议错误，并使用活动计时器检测会话挂起情况。这些机制与端到端控件是分开的。
If a protocol error occurs, the session will be terminated and application activity aborted. Both locations enter the IDLE state.
如果发生协议错误，会话将终止，应用程序活动将中止。两个位置都进入空闲状态。
To protect against application and network hang conditions, ODETTE-FTP uses activity timers for all situations where a response is required. The timers and actions to be taken if they expire are described in Section 9, "Protocol State Machine".
为了防止应用程序和网络挂起情况，ODETTE-FTP在需要响应的所有情况下都使用活动计时器。第9节“协议状态机”中描述了计时器和过期时要采取的措施。
The use of clearing centres introduces the possibility of errors occurring as a result of data processing activities within the centre. Such errors are not directly related to ODETTE-FTP or the communication network and are therefore outside the scope of this specification.
清算中心的使用引入了由于中心内的数据处理活动而发生错误的可能性。此类错误与ODETTE-FTP或通信网络没有直接关系，因此不在本规范的范围内。
ODETTE-FTP entities communicate via Exchange Buffers. The Command Exchange Buffers are described below. Virtual File data is carried in Data Exchange Buffers, which are described in Section 7.
ODETTE-FTP实体通过交换缓冲区进行通信。命令交换缓冲区描述如下。虚拟文件数据在数据交换缓冲区中传输，如第7节所述。
The basic unit of information is an octet, containing 8 bits.
信息的基本单位是八位字节，包含8位。
The ISO 646 IRV 7-bit coded character set [ISO-646], according to Appendix B, is used to encode constants and strings within Command Exchange Buffers except where [UTF-8] is explicitly indicated against a field.
根据附录B，ISO 646 IRV 7位编码字符集[ISO-646]用于对命令交换缓冲区内的常量和字符串进行编码，除非[UTF-8]在字段中明确指示。
A Command Exchange Buffer contains a single command starting at the beginning of the buffer. Commands and data are never mixed within an Exchange Buffer. Commands cannot be compressed. Variable-length parameters may be omitted entirely if not required and the associated length indicator field set to zero.
命令交换缓冲区包含从缓冲区开始的单个命令。命令和数据永远不会在Exchange缓冲区中混合。命令不能被压缩。如果不需要，可变长度参数可以完全省略，并且相关的长度指示器字段设置为零。
Components:
组件：
1. Command identifier:
1. 命令标识符：
The first octet of an Exchange Buffer is the Command Identifier and defines the format of the buffer.
交换缓冲区的第一个八位字节是命令标识符，定义缓冲区的格式。
2. Parameter(s):
2. 参数：
Command parameters are stored in fields within a Command Exchange Buffer. Where variable-length fields are used, they are preceded with a header field indicating the length. All values are required except where explicitly indicated.
命令参数存储在命令交换缓冲区内的字段中。在使用可变长度字段的情况下，它们前面会有一个指示长度的标题字段。除明确指示外，所有值都是必需的。
The ODETTE-FTP commands are described below using the following definitions.
下面使用以下定义描述ODETTE-FTP命令。
Position (Pos)
位置（Pos）
Field offset within the Command Exchange Buffer, relative to a zero origin.
命令交换缓冲区内相对于零原点的字段偏移量。
Field
领域
The name of the field.
字段的名称。
Description
描述
A description of the field.
字段的描述。
Format
总体安排
F - A field containing fixed values. All allowable values for the field are enumerated in the command definition.
F-包含固定值的字段。该字段的所有允许值都在命令定义中枚举。
V - A field with variable values within a defined range. For example, the SFIDLRECL field may contain any integer value between 00000 and 99999.
V-在定义范围内具有可变值的字段。例如，SFIDLRECL字段可能包含00000到99999之间的任何整数值。
X(n) - An alphanumeric field of length n octets.
X（n）-长度为n个八位字节的字母数字字段。
A String contains alphanumeric characters from the following set:
字符串包含以下集合中的字母数字字符：
The numerals: 0 to 9 The upper case letters: A to Z The following special set: / - . & ( ) space.
数字：0到9大写字母：A到Z以下特殊集合：/-.&（）空间。
Space is not allowed as an embedded character.
不允许将空格作为嵌入字符。
9(n) - A numeric field of length n octets.
9（n）-长度为n个八位字节的数字字段。
U(n) - A binary field of length n octets.
U（n）-长度为n个八位字节的二进制字段。
Numbers encoded as binary are always unsigned and in network byte order.
编码为二进制的数字总是无符号的，并且按网络字节顺序。
T(n) - An field of length n octets, encoded using [UTF-8].
T（n）-长度为n个八位字节的字段，使用[UTF-8]编码。
String and alphanumeric fields are always left justified and right padded with spaces where needed.
字符串和字母数字字段总是左对齐，需要时用空格右填充。
Numeric fields are always right justified and left padded with zeros where needed.
数字字段总是右对齐，需要时用零填充。
Reserved fields should be padded with spaces.
保留字段应填充空格。
o-------------------------------------------------------------------o
| SSRM Start Session Ready Message |
| |
| Start Session Phase Initiator <---- Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SSRMCMD | SSRM Command, 'I' | F X(1) |
| 1 | SSRMMSG | Ready Message, 'ODETTE FTP READY ' | F X(17) |
| 18 | SSRMCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| SSRM Start Session Ready Message |
| |
| Start Session Phase Initiator <---- Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SSRMCMD | SSRM Command, 'I' | F X(1) |
| 1 | SSRMMSG | Ready Message, 'ODETTE FTP READY ' | F X(17) |
| 18 | SSRMCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
SSRMCMD Command Code Character
SSRMCD命令代码字符
Value: 'I' SSRM Command identifier.
值：“I”SSRM命令标识符。
SSRMMSG Ready Message String(17)
SSRMMSG就绪消息字符串（17）
Value: 'ODETTE FTP READY '
值：“ODETTE FTP就绪”
SSRMCR Carriage Return Character
SSRMCR回车符
Value: Character with hex value '0D' or '8D'.
值：具有十六进制值“0D”或“8D”的字符。
o-------------------------------------------------------------------o
| SSID Start Session |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SSIDCMD | SSID Command 'X' | F X(1) |
| 1 | SSIDLEV | Protocol Release Level | F 9(1) |
| 2 | SSIDCODE | Initiator's Identification Code | V X(25) |
| 27 | SSIDPSWD | Initiator's Password | V X(8) |
| 35 | SSIDSDEB | Data Exchange Buffer Size | V 9(5) |
| 40 | SSIDSR | Send / Receive Capabilities (S/R/B) | F X(1) |
| 41 | SSIDCMPR | Buffer Compression Indicator (Y/N) | F X(1) |
| 42 | SSIDREST | Restart Indicator (Y/N) | F X(1) |
| 43 | SSIDSPEC | Special Logic Indicator (Y/N) | F X(1) |
| 44 | SSIDCRED | Credit | V 9(3) |
| 47 | SSIDAUTH | Secure Authentication (Y/N) | F X(1) |
| 48 | SSIDRSV1 | Reserved | F X(4) |
| 52 | SSIDUSER | User Data | V X(8) |
| 60 | SSIDCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| SSID Start Session |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SSIDCMD | SSID Command 'X' | F X(1) |
| 1 | SSIDLEV | Protocol Release Level | F 9(1) |
| 2 | SSIDCODE | Initiator's Identification Code | V X(25) |
| 27 | SSIDPSWD | Initiator's Password | V X(8) |
| 35 | SSIDSDEB | Data Exchange Buffer Size | V 9(5) |
| 40 | SSIDSR | Send / Receive Capabilities (S/R/B) | F X(1) |
| 41 | SSIDCMPR | Buffer Compression Indicator (Y/N) | F X(1) |
| 42 | SSIDREST | Restart Indicator (Y/N) | F X(1) |
| 43 | SSIDSPEC | Special Logic Indicator (Y/N) | F X(1) |
| 44 | SSIDCRED | Credit | V 9(3) |
| 47 | SSIDAUTH | Secure Authentication (Y/N) | F X(1) |
| 48 | SSIDRSV1 | Reserved | F X(4) |
| 52 | SSIDUSER | User Data | V X(8) |
| 60 | SSIDCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
SSIDCMD Command Code Character
SSIDCMD命令代码字符
Value: 'X' SSID Command identifier.
值：“X”SSID命令标识符。
SSIDLEV Protocol Release Level Numeric(1)
SSIDLEV协议发布级别数字（1）
Used to specify the level of the ODETTE-FTP protocol
用于指定ODETTE-FTP协议的级别
Value: '1' for Revision 1.2 '2' for Revision 1.3 '4' for Revision 1.4 '5' for Revision 2.0
值：“1”表示修订版1.2“2”表示修订版1.3“4”表示修订版1.4“5”表示修订版2.0
Future release levels will have higher numbers. The protocol release level is negotiable, with the lowest level being selected.
未来的发布级别将有更高的数字。协议发布级别可以协商，选择最低级别。
Note: ODETTE File Transfer Protocol 1.3 (RFC 2204) specifies '1' for the release level, despite adhering to revision 1.3.
注：ODETTE文件传输协议1.3（RFC 2204）规定发布级别为“1”，尽管遵守版本1.3。
SSIDCODE Initiator's Identification Code String(25)
SSIDCODE启动器的标识码字符串（25）
Format: See Identification Code (Section 5.4)
格式：见识别码（第5.4节）
Uniquely identifies the Initiator (sender) participating in the ODETTE-FTP session.
唯一标识参与ODETTE-FTP会话的启动器（发送方）。
It is an application implementation issue to link the expected [X.509] certificate to the SSIDCODE provided.
将预期的[X.509]证书链接到提供的SSIDCODE是应用程序实现问题。
SSIDPSWD Initiator's Password String(8)
SSIDPSWD启动器的密码字符串（8）
Key to authenticate the sender. Assigned by bilateral agreement.
验证发件人身份的密钥。通过双边协议转让。
SSIDSDEB Data Exchange Buffer Size Numeric(5)
SSIDSDEB数据交换缓冲区大小数字（5）
Minimum: 128 Maximum: 99999
最小值：128最大值：99999
The length, in octets, of the largest Data Exchange Buffer that can be accepted by the location. The length includes the command octet but does not include the Stream Transmission Header.
位置可以接受的最大数据交换缓冲区的长度（以八位字节为单位）。长度包括命令八位字节，但不包括流传输头。
After negotiation, the smallest size will be selected.
协商后，将选择最小尺寸。
SSIDSR Send / Receive Capabilities Character
SSIDSR发送/接收功能字符
Value: 'S' Location can only send files. 'R' Location can only receive files. 'B' Location can both send and receive files.
值：“S”位置只能发送文件R'位置只能接收文件。'“B”位置可以发送和接收文件。
Sending and receiving will be serialised during the session, so parallel transmissions will not take place in the same session.
发送和接收将在会话期间序列化，因此并行传输不会在同一会话中发生。
An error occurs if adjacent locations both specify the send or receive capability.
如果相邻位置都指定了发送或接收功能，则会发生错误。
SSIDCMPR Buffer Compression Indicator Character
SSIDCMPR缓冲区压缩指示符字符
Value: 'Y' The location can handle OFTP data buffer compression 'N' The location cannot handle OFTP buffer compression
值：“Y”该位置可以处理OFTP数据缓冲区压缩“N”该位置无法处理OFTP缓冲区压缩
Compression is only used if supported by both locations.
仅当两个位置都支持时才使用压缩。
The compression mechanism referred to here applies to each individual OFTP data buffer. This is different from the file compression mechanism in OFTP, which involves the compression of whole files.
这里提到的压缩机制适用于每个单独的OFTP数据缓冲区。这与OFTP中的文件压缩机制不同，后者涉及整个文件的压缩。
SSIDREST Restart Indicator Character
SSIDREST重新启动指示符字符
Value: 'Y' The location can handle the restart of a partially transmitted file. 'N' The location cannot restart a file.
值：“Y”该位置可以处理部分传输文件的重新启动N'该位置无法重新启动文件。
SSIDSPEC Special Logic Indicator Character
SSIDSPEC特殊逻辑指示器字符
Value: 'Y' Location can handle Special Logic 'N' Location cannot handle Special Logic
值：“Y”位置可以处理特殊逻辑“N”位置无法处理特殊逻辑
Special Logic is only used if supported by both locations.
仅当两个位置都支持时，才使用特殊逻辑。
The Special Logic extensions are only useful to access an X.25 network via an asynchronous entry and are not supported for TCP/IP connections.
特殊逻辑扩展仅用于通过异步条目访问X.25网络，不支持TCP/IP连接。
SSIDCRED Credit Numeric(3)
SSIDCRED信用数字（3）
Maximum: 999
最高限额：999
The number of consecutive Data Exchange Buffers sent by the Speaker before it must wait for a Credit (CDT) command from the Listener.
在必须等待来自侦听器的Credit（CDT）命令之前，扬声器发送的连续数据交换缓冲区数。
The credit value is only applied to Data flow in the Data Transfer phase.
信用值仅应用于数据传输阶段的数据流。
The Speaker's available credit is initialised to SSIDCRED when it receives a Start File Positive Answer (SFPA) command from the Listener. It is zeroed by the End File (EFID) command.
当演讲者从听者处收到开始文件肯定应答（SFPA）命令时，演讲者的可用信用被初始化为SSIDCRED。它由End File（EFID）命令归零。
After negotiation, the smallest size must be selected in the answer of the Responder, otherwise a protocol error will abort the session.
协商后，必须在响应者的回答中选择最小的大小，否则协议错误将中止会话。
Negotiation of the "credit-window-size" parameter.
协商“信贷窗口大小”参数。
Window Size m -- SSID ------------>
<------------ SSID -- Window Size n
(n less than or
equal to m)
Note: negotiated value will be "n".
Window Size m -- SSID ------------>
<------------ SSID -- Window Size n
(n less than or
equal to m)
Note: negotiated value will be "n".
SSIDAUTH Secure Authentication Character
SSIDAUTH安全身份验证字符
Value: 'Y' The location requires secure authentication. 'N' The location does not require secure authentication.
值：“Y”该位置需要安全身份验证N'该位置不需要安全身份验证。
Secure authentication is only used if agreed by both locations.
只有在双方同意的情况下，才使用安全身份验证。
If the answer of the Responder does not match with the authentication requirements of the Initiator, then the Initiator must abort the session.
如果响应者的回答与启动器的身份验证要求不匹配，则启动器必须中止会话。
No negotiation of authentication is allowed.
不允许协商身份验证。
authentication p -- SSID ------------>
<------------ SSID -- authentication q
authentication p -- SSID ------------>
<------------ SSID -- authentication q
p == q -> continue. p != q -> abort.
p==q->继续。p！=q->中止。
SSIDRSV1 Reserved String(4)
SSIDRSV1保留字符串（4）
This field is reserved for future use.
此字段保留供将来使用。
SSIDUSER User Data String(8)
SSIDUSER用户数据字符串（8）
May be used by ODETTE-FTP in any way. If unused, it should be initialised to spaces. It is expected that a bilateral agreement exists as to the meaning of the data.
可由ODETTE-FTP以任何方式使用。如果未使用，则应将其初始化为空格。预计将就数据的含义达成双边协议。
SSIDCR Carriage Return Character
SSIDCR回车符
Value: Character with hex value '0D' or '8D'.
值：具有十六进制值“0D”或“8D”的字符。
o-------------------------------------------------------------------o
| SFID Start File |
| |
| Start File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SFIDCMD | SFID Command, 'H' | F X(1) |
| 1 | SFIDDSN | Virtual File Dataset Name | V X(26) |
| 27 | SFIDRSV1 | Reserved | F X(3) |
| 30 | SFIDDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) |
| 38 | SFIDTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) |
| 48 | SFIDUSER | User Data | V X(8) |
| 56 | SFIDDEST | Destination | V X(25) |
| 81 | SFIDORIG | Originator | V X(25) |
| 106 | SFIDFMT | File Format (F/V/U/T) | F X(1) |
| 107 | SFIDLRECL | Maximum Record Size | V 9(5) |
| 112 | SFIDFSIZ | File Size, 1K blocks | V 9(13) |
| 125 | SFIDOSIZ | Original File Size, 1K blocks | V 9(13) |
| 138 | SFIDREST | Restart Position | V 9(17) |
| 155 | SFIDSEC | Security Level | F 9(2) |
| 157 | SFIDCIPH | Cipher suite selection | F 9(2) |
| 159 | SFIDCOMP | File compression algorithm | F 9(1) |
| 160 | SFIDENV | File enveloping format | F 9(1) |
| 161 | SFIDSIGN | Signed EERP request | F X(1) |
| 162 | SFIDDESCL | Virtual File Description length | V 9(3) |
| 165 | SFIDDESC | Virtual File Description | V T(n) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| SFID Start File |
| |
| Start File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SFIDCMD | SFID Command, 'H' | F X(1) |
| 1 | SFIDDSN | Virtual File Dataset Name | V X(26) |
| 27 | SFIDRSV1 | Reserved | F X(3) |
| 30 | SFIDDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) |
| 38 | SFIDTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) |
| 48 | SFIDUSER | User Data | V X(8) |
| 56 | SFIDDEST | Destination | V X(25) |
| 81 | SFIDORIG | Originator | V X(25) |
| 106 | SFIDFMT | File Format (F/V/U/T) | F X(1) |
| 107 | SFIDLRECL | Maximum Record Size | V 9(5) |
| 112 | SFIDFSIZ | File Size, 1K blocks | V 9(13) |
| 125 | SFIDOSIZ | Original File Size, 1K blocks | V 9(13) |
| 138 | SFIDREST | Restart Position | V 9(17) |
| 155 | SFIDSEC | Security Level | F 9(2) |
| 157 | SFIDCIPH | Cipher suite selection | F 9(2) |
| 159 | SFIDCOMP | File compression algorithm | F 9(1) |
| 160 | SFIDENV | File enveloping format | F 9(1) |
| 161 | SFIDSIGN | Signed EERP request | F X(1) |
| 162 | SFIDDESCL | Virtual File Description length | V 9(3) |
| 165 | SFIDDESC | Virtual File Description | V T(n) |
o-------------------------------------------------------------------o
SFIDCMD Command Code Character
SFIDCMD命令代码字符
Value: 'H' SFID Command identifier.
值：“H”SFID命令标识符。
SFIDDSN Virtual File Dataset Name String(26)
SFIDDSN虚拟文件数据集名称字符串（26）
Dataset name of the Virtual File being transferred, assigned by bilateral agreement.
正在传输的虚拟文件的数据集名称，由双边协议指定。
No general structure is defined for this attribute.
没有为此属性定义常规结构。
See Virtual Files - Identification (Section 1.5.2)
见虚拟文件-标识（第1.5.2节）
SFIDRSV1 Reserved String(3)
SFIDRSV1保留字符串（3）
This field is reserved for future use.
此字段保留供将来使用。
SFIDDATE Virtual File Date stamp Numeric(8)
SFIDDATE虚拟文件日期戳数字（8）
Format: 'CCYYMMDD' 8 decimal digits representing the century, year, month, and day.
格式：“CCYYMMDD”8位十进制数字，表示世纪、年、月和日。
Date stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
由虚拟文件的发起人指定的日期戳，指示文件何时可用于传输。
See Virtual Files - Identification (Section 1.5.2)
见虚拟文件-标识（第1.5.2节）
SFIDTIME Virtual File Time stamp Numeric(10)
SFIDTIME虚拟文件时间戳数字（10）
Format: 'HHMMSScccc' 10 decimal digits representing hours, minutes, seconds, and a counter (0001-9999), which gives higher resolution.
格式：“HHMMSScccc”10位十进制数字，代表小时、分钟、秒和计数器（0001-9999），可提供更高的分辨率。
Time stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
由虚拟文件的发起人指定的时间戳，指示文件何时可用于传输。
See Virtual Files - Identification (Section 1.5.2)
见虚拟文件-标识（第1.5.2节）
SFIDUSER User Data String(8)
SFIDUSER用户数据字符串（8）
May be used by ODETTE-FTP in any way. If unused, it should be initialised to spaces. It is expected that a bilateral agreement exists as to the meaning of the data.
可由ODETTE-FTP以任何方式使用。如果未使用，则应将其初始化为空格。预计将就数据的含义达成双边协议。
SFIDDEST Destination String(25)
SFIDDEST目标字符串（25）
Format: See Identification Code (Section 5.4)
格式：见识别码（第5.4节）
The Final Recipient of the Virtual File.
虚拟文件的最终收件人。
This is the location that will look into the Virtual File content and perform mapping functions. It is also the location that creates the End to End Response (EERP) command for the received file.
这是查看虚拟文件内容并执行映射功能的位置。它也是为接收的文件创建端到端响应（EERP）命令的位置。
SFIDORIG Originator String(25)
SFIDORIG发起者字符串（25）
Format: See Identification Code (Section 5.4)
格式：见识别码（第5.4节）
Originator of the Virtual File.
虚拟文件的发起人。
It is the location that created (mapped) the data for transmission.
它是创建（映射）传输数据的位置。
SFIDFMT File Format Character
SFIDFMT文件格式字符
Value: 'F' Fixed format binary file 'V' Variable format binary file 'U' Unstructured binary file 'T' Text
值：“F”固定格式二进制文件“V”可变格式二进制文件“U”非结构化二进制文件“T”文本
Virtual File format. Used to calculate the restart position (Section 1.5.4).
虚拟文件格式。用于计算重启位置（第1.5.4节）。
Once a file has been signed, compressed, and/or encrypted, in file format terms it becomes unstructured, format U. The record boundaries are no longer discernable until the file is decrypted, decompressed, and/or verified. SFID File Format Field in this scenario indicates the format of the original file, and the transmitted file must be treated as U format.
一旦文件被签名、压缩和/或加密，以文件格式而言，它将变为非结构化格式U。在对文件进行解密、解压缩和/或验证之前，记录边界不再可见。此场景中的SFID文件格式字段表示原始文件的格式，传输的文件必须视为U格式。
SFIDLRECL Maximum Record Size Numeric(5)
SFIDLREL最大记录大小数字（5）
Maximum: 99999
最高：99999
Length in octets of the longest logical record that may be transferred to a location. Only user data is included.
可以传输到某个位置的最长逻辑记录的长度（以八位字节为单位）。只包括用户数据。
If SFIDFMT is 'T' or 'U', then this attribute must be set to '00000'.
如果SFIDFMT为“T”或“U”，则此属性必须设置为“00000”。
If SFIDFMT is 'V' and the file is compressed, encrypted, or signed, then the maximum value of SFIDRECL is '65536'.
如果SFIDFMT为“V”，且文件已压缩、加密或签名，则SFIDRECL的最大值为“65536”。
SFIDFSIZ Transmitted File Size Numeric(13)
SFIDFSIZ传输的文件大小数字（13）
Maximum: 9999999999999
最大值：9999999999
Space in 1K (1024 octet) blocks required at the Originator location to store the actual Virtual File that is to be transmitted.
发起者位置存储要传输的实际虚拟文件所需的1K（1024个八位组）块空间。
For example, if a file is compressed before sending, then this is the space required to store the compressed file.
例如，如果文件在发送前已压缩，则这是存储压缩文件所需的空间。
This parameter is intended to provide only a good estimate of the Virtual File size.
此参数旨在提供虚拟文件大小的良好估计。
Using 13 digits allows for a maximum file size of approximately 9.3 PB (petabytes) to be transmitted.
使用13位允许传输的最大文件大小约为9.3 PB（PB）。
SFIDOSIZ Original File Size Numeric(13)
SFIDOSIZ原始文件大小数字（13）
Maximum: 9999999999999
最大值：9999999999
Space in 1K (1024 octet) blocks required at the Originator location to store the original before it was signed, compressed, and/or encrypted.
在签名、压缩和/或加密原件之前，发起者位置存储原件所需的1K（1024个八位组）块空间。
If no security or compression services have been used, SFIDOSIZ should contain the same value as SFIDFSIZ.
如果未使用安全或压缩服务，则SFIDOSIZ应包含与SFIDFSIZ相同的值。
If the original file size is not known, the value zero should be used.
如果原始文件大小未知，则应使用值零。
This parameter is intended to provide only a good estimate of the original file size.
此参数仅用于提供原始文件大小的良好估计。
The sequence of events in file exchange are:
文件交换中的事件顺序为：
(a) raw data file ready to be sent SFIDOSIZ = Original File Size
(a) 准备发送的原始数据文件SFIDOSIZ=原始文件大小
(b) signing/compression/encryption
(b) 签名/压缩/加密
(c) transmission SFIDFSIZ = Transmitted File Size
(c) 传输SFIDFSIZ=传输的文件大小
(d) decryption/decompression/verification
(d) 解密/解压缩/验证
(e) received raw data file for in-house applications SFIDOSIZ = Original File Size
(e) 接收到内部应用程序的原始数据文件SFIDOSIZ=原始文件大小
The Transmitted File Size at (c) indicates to the receiver how much storage space is needed to receive the file.
（c）处的传输文件大小向接收器指示接收文件需要多少存储空间。
The Original File Size at (e) indicates to the in-house application how much storage space is needed to process the file.
（e）处的原始文件大小向内部应用程序指示处理文件需要多少存储空间。
SFIDREST Restart Position Numeric(17)
SFIDREST重新启动位置数字（17）
Maximum: 99999999999999999
最大值：999999999999
Virtual File restart position.
虚拟文件重新启动位置。
The count represents the: - Record Number if SSIDFMT is 'F' or 'V'. - File offset in 1K (1024 octet) blocks if SFIDFMT is 'U' or 'T'.
如果SSIDFMT为“F”或“V”，则计数表示：-记录编号如果SFIDFMT为“U”或“T”，则文件偏移量以1K（1024个八位字节）块为单位。
The count will express the transmitted user data (i.e., before ODETTE-FTP buffer compression, header not included).
计数将表示传输的用户数据（即，在ODETTE-FTP缓冲区压缩之前，不包括标头）。
After negotiation between adjacent locations, retransmission will start at the lowest value.
在相邻位置之间协商后，重传将以最低值开始。
Once a file has been signed, compressed, and/or encrypted, in file format terms, it has become unstructured, like format U. The file should be treated as format U for the purposes of restart, regardless of the actual value in SFIDFMT.
一旦文件以文件格式进行了签名、压缩和/或加密，它就变成了非结构化文件，如格式U。为了重新启动，无论SFIDFMT中的实际值如何，该文件都应被视为格式U。
SFIDSEC Security Level Numeric(2)
SFIDSEC安全级别数字（2）
Value: '00' No security services '01' Encrypted '02' Signed '03' Encrypted and signed
值：“00”无安全服务“01”加密“02”签名“03”加密并签名
Indicates whether the file has been signed and/or encrypted before transmission. (See Section 6.2.)
指示文件在传输之前是否已签名和/或加密。（见第6.2节。）
SFIDCIPH Cipher suite selection Numeric(2)
SFIDCIPH密码套件选择数字（2）
Value: '00' No security services '01' See Section 10.2
值：“00”无安全服务“01”见第10.2节
Indicates the cipher suite used to sign and/or encrypt the file and also to indicate the cipher suite that should be used when a signed EERP or NERP is requested.
指示用于对文件进行签名和/或加密的密码套件，以及在请求签名的EERP或NERP时应使用的密码套件。
SFIDCOMP File compression algorithm Numeric(1)
SFIDCOMP文件压缩算法数值（1）
Value: '0' No compression '1' Compressed with [ZLIB] algorithm
值：“0”没有使用[ZLIB]算法压缩的压缩“1”
Indicates the algorithm used to compress the file. (See Section 6.4.)
指示用于压缩文件的算法。（见第6.4节。）
SFIDENV File enveloping format Numeric(1)
SFIDENV文件封装格式数字（1）
Value: '0' No envelope '1' File is enveloped using [CMS]
值：“0”没有使用[CMS]封装信封“1”文件
Indicates the enveloping format used in the file.
指示文件中使用的信封格式。
If the file is encrypted/signed/compressed or is an enveloped file for the exchange and revocation of certificates, this field must be set accordingly.
如果文件是加密/签名/压缩的，或者是用于交换和撤销证书的封装文件，则必须相应地设置此字段。
SFIDSIGN Signed EERP request Character
SFIDSIGN签名EERP请求字符
Value: 'Y' The EERP returned in acknowledgement of the file must be signed 'N' The EERP must not be signed
值：“Y”在确认文件时返回的EERP必须签名“N”EERP不能签名
Requests whether the EERP returned for the file must be signed.
请求是否必须对为文件返回的EERP进行签名。
SFIDDESCL Virtual File Description length Numeric(3)
SFIDDESCL虚拟文件描述长度数字（3）
Length in octets of the field SFIDDESC.
字段SFIDDESC的长度（以八位字节为单位）。
A value of 0 indicates that no description is present.
值为0表示不存在描述。
SFIDDESC Virtual File Description [UTF-8](n)
SFIDDESC虚拟文件描述[UTF-8]（n）
May be used by ODETTE-FTP in any way. If not used, SFIDDESCL should be set to zero.
可由ODETTE-FTP以任何方式使用。如果未使用，则应将SFIDDESCL设置为零。
No general structure is defined for this attribute, but it is expected that a bilateral agreement exists as to the meaning of the data.
没有为该属性定义一般结构，但预计就数据的含义存在双边协议。
It is encoded using [UTF-8] to support a range of national languages.
它使用[UTF-8]编码以支持一系列国家语言。
Maximum length of the encoded value is 999 octets.
编码值的最大长度为999个八位字节。
o-------------------------------------------------------------------o
| SFPA Start File Positive Answer |
| |
| Start File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SFPACMD | SFPA Command, '2' | F X(1) |
| 1 | SFPAACNT | Answer Count | V 9(17) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| SFPA Start File Positive Answer |
| |
| Start File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SFPACMD | SFPA Command, '2' | F X(1) |
| 1 | SFPAACNT | Answer Count | V 9(17) |
o-------------------------------------------------------------------o
SFPACMD Command Code Character
SFPACMD命令代码字符
Value: '2' SFPA Command identifier.
值：“2”SFPA命令标识符。
SFPAACNT Answer Count Numeric(17)
SFPAACNT应答计数数字（17）
The Listener must enter a count lower than or equal to the restart count specified by the Speaker in the Start File (SFID) command. The count expresses the received user data. If restart facilities are not available, a count of zero must be specified.
侦听器输入的计数必须小于或等于扬声器在“开始文件”（SFID）命令中指定的重新启动计数。计数表示接收到的用户数据。如果重新启动设施不可用，则必须指定零计数。
o-------------------------------------------------------------------o
| SFNA Start File Negative Answer |
| |
| Start File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SFNACMD | SFNA Command, '3' | F X(1) |
| 1 | SFNAREAS | Answer Reason | F 9(2) |
| 3 | SFNARRTR | Retry Indicator, (Y/N) | F X(1) |
| 4 | SFNAREASL | Answer Reason Text Length | V 9(3) |
| 7 | SFNAREAST | Answer Reason Text | V T(n) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| SFNA Start File Negative Answer |
| |
| Start File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SFNACMD | SFNA Command, '3' | F X(1) |
| 1 | SFNAREAS | Answer Reason | F 9(2) |
| 3 | SFNARRTR | Retry Indicator, (Y/N) | F X(1) |
| 4 | SFNAREASL | Answer Reason Text Length | V 9(3) |
| 7 | SFNAREAST | Answer Reason Text | V T(n) |
o-------------------------------------------------------------------o
SFNACMD Command Code Character
SFNACMD命令代码字符
Value: '3' SFNA Command identifier.
值：“3”SFNA命令标识符。
SFNAREAS Answer Reason Numeric(2)
SFNAREAS答案原因数字（2）
Value: '01' Invalid filename. '02' Invalid destination. '03' Invalid origin. '04' Storage record format not supported. '05' Maximum record length not supported. '06' File size is too big. '10' Invalid record count. '11' Invalid byte count. '12' Access method failure. '13' Duplicate file. '14' File direction refused. '15' Cipher suite not supported. '16' Encrypted file not allowed. '17' Unencrypted file not allowed. '18' Compression not allowed. '19' Signed file not allowed. '20' Unsigned file not allowed. '99' Unspecified reason.
值：“01”文件名无效02“目标无效。”03“无效来源”04“不支持存储记录格式。”05“不支持最大记录长度。”06“文件大小太大。”10“无效记录计数”11“无效字节计数”12“访问方法失败”13“重复文件”14“文件方向被拒绝。”15“不支持密码套件。”16“不允许使用加密文件。”17“不允许使用未加密的文件。”18“不允许压缩。”19“不允许使用签名文件。”20“不允许使用未签名的文件。”99'未指明原因。
Reason why transmission cannot proceed.
传输无法继续的原因。
SFNARRTR Retry Indicator Character
SFNARRTR重试指示符字符
Value: 'N' Transmission should not be retried. 'Y' The transmission may be retried later.
值：“N”不应重试传输Y’稍后可能会重试传输。
This parameter is used to advise the Speaker if it should retry at a later time due to a temporary condition at the Listener site, such as a lack of storage space. It should be used in conjunction with the Answer Reason code (SFNAREAS).
此参数用于建议说话人是否应在以后重试，因为侦听器站点存在临时情况，例如缺少存储空间。它应与应答原因码（SFNAREAS）一起使用。
An invalid file name error code may be the consequence of a problem in the mapping of the Virtual File on to a real file. Such problems cannot always be resolved immediately. It is therefore recommended that when an SFNA with Retry = Y is received the User Monitor attempts to retransmit the relevant file in a subsequent session.
无效的文件名错误代码可能是虚拟文件映射到真实文件时出现问题的结果。这些问题不可能总是立即得到解决。因此，建议当接收到重试=Y的SFNA时，用户监视器尝试在后续会话中重新传输相关文件。
SFNAREASL Answer Reason Text Length Numeric(3)
SFNAREASL答案原因文本长度数字（3）
Length in octets of the field SFNAREAST.
字段SFNAREAST的长度（以八位字节为单位）。
0 indicates that no SFNAREAST field follows.
0表示后面没有SFNAREAST字段。
SFNAREAST Answer Reason Text [UTF-8](n)
SFNAREST应答原因文本[UTF-8]（n）
Reason why transmission cannot proceed in plain text.
无法以纯文本进行传输的原因。
It is encoded using [UTF-8].
使用[UTF-8]对其进行编码。
Maximum length of the encoded reason is 999 octets.
编码原因的最大长度为999个八位字节。
No general structure is defined for this attribute.
没有为此属性定义常规结构。
o-------------------------------------------------------------------o
| DATA Data Exchange Buffer |
| |
| Data Transfer Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | DATACMD | DATA Command, 'D' | F X(1) |
| 1 | DATABUF | Data Exchange Buffer payload | V U(n) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| DATA Data Exchange Buffer |
| |
| Data Transfer Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | DATACMD | DATA Command, 'D' | F X(1) |
| 1 | DATABUF | Data Exchange Buffer payload | V U(n) |
o-------------------------------------------------------------------o
DATACMD Command Code Character
DATACMD命令代码字符
Value: 'D' DATA Command identifier.
值：“D”数据命令标识符。
DATABUF Data Exchange Buffer payload Binary(n)
DATABUF数据交换缓冲区有效负载二进制（n）
Variable-length buffer containing the data payload. The Data Exchange Buffer is described in Section 7.
包含数据有效负载的可变长度缓冲区。第7节介绍了数据交换缓冲区。
o-------------------------------------------------------------------o
| CDT Set Credit |
| |
| Data Transfer Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | CDTCMD | CDT Command, 'C' | F X(1) |
| 1 | CDTRSV1 | Reserved | F X(2) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| CDT Set Credit |
| |
| Data Transfer Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | CDTCMD | CDT Command, 'C' | F X(1) |
| 1 | CDTRSV1 | Reserved | F X(2) |
o-------------------------------------------------------------------o
CDTCMD Command Code Character
CDTCMD命令代码字符
Value: 'C' CDT Command identifier.
值：“C”CDT命令标识符。
CDTRSV1 Reserved String(2)
CDTRSV1保留字符串（2）
This field is reserved for future use.
此字段保留供将来使用。
o-------------------------------------------------------------------o
| EFID End File |
| |
| End File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EFIDCMD | EFID Command, 'T' | F X(1) |
| 1 | EFIDRCNT | Record Count | V 9(17) |
| 18 | EFIDUCNT | Unit Count | V 9(17) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| EFID End File |
| |
| End File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EFIDCMD | EFID Command, 'T' | F X(1) |
| 1 | EFIDRCNT | Record Count | V 9(17) |
| 18 | EFIDUCNT | Unit Count | V 9(17) |
o-------------------------------------------------------------------o
EFIDCMD Command Code Character
EFIDCMD命令代码字符
Value: 'T' EFID Command identifier.
值：“T”EFID命令标识符。
EFIDRCNT Record Count Numeric(17)
EFIDRCNT记录计数数字（17）
Maximum: 99999999999999999
最大值：999999999999
For SSIDFMT 'F' or 'V', the exact record count. For SSIDFMT 'U' or 'T', zeros.
对于SSIDFMT“F”或“V”，精确的记录计数。对于SSIDFMT“U”或“T”，为零。
The count will express the real size of the file (before buffer compression, header not included). The total count is always used, even during restart processing.
计数将表示文件的实际大小（在缓冲区压缩之前，不包括头）。即使在重新启动处理期间，也始终使用总计数。
EFIDUCNT Unit Count Numeric(17)
电子感应单位计数数字（17）
Maximum: 99999999999999999
最大值：999999999999
Exact number of units (octets) transmitted.
传输的准确单位数（八位字节）。
The count will express the real size of the file. The total count is always used, even during restart processing.
计数将表示文件的实际大小。即使在重新启动处理期间，也始终使用总计数。
o-------------------------------------------------------------------o
| EFPA End File Positive Answer |
| |
| End File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EFPACMD | EFPA Command, '4' | F X(1) |
| 1 | EFPACD | Change Direction Indicator, (Y/N) | F X(1) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| EFPA End File Positive Answer |
| |
| End File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EFPACMD | EFPA Command, '4' | F X(1) |
| 1 | EFPACD | Change Direction Indicator, (Y/N) | F X(1) |
o-------------------------------------------------------------------o
EFPACMD Command Code Character
EFPACMD命令代码字符
Value: '4' EFPA Command identifier.
值：“4”EFPA命令标识符。
EFPACD Change Direction Indicator Character
EFPACD转向指示器字符
Value: 'N' Change direction not requested. 'Y' Change direction requested.
值：“N”未请求更改方向你需要改变方向。
This parameter allows the Listener to request a Change Direction (CD) command from the Speaker.
此参数允许侦听器从扬声器请求更改方向（CD）命令。
o-------------------------------------------------------------------o
| EFNA End File Negative Answer |
| |
| End File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EFNACMD | EFNA Command, '5' | F X(1) |
| 1 | EFNAREAS | Answer Reason | F 9(2) |
| 3 | EFNAREASL | Answer Reason Text Length | V 9(3) |
| 6 | EFNAREAST | Answer Reason Text | V T(n) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| EFNA End File Negative Answer |
| |
| End File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EFNACMD | EFNA Command, '5' | F X(1) |
| 1 | EFNAREAS | Answer Reason | F 9(2) |
| 3 | EFNAREASL | Answer Reason Text Length | V 9(3) |
| 6 | EFNAREAST | Answer Reason Text | V T(n) |
o-------------------------------------------------------------------o
EFNACMD Command Code Character
EFNACMD命令代码字符
Value: '5' EFNA Command identifier.
值：“5”EFNA命令标识符。
EFNAREAS Answer Reason Numeric(2)
EFNAREAS答案原因数字（2）
Value: '01' Invalid filename. '02' Invalid destination. '03' Invalid origin. '04' Storage record format not supported. '05' Maximum record length not supported. '06' File size is too big. '10' Invalid record count. '11' Invalid byte count. '12' Access method failure. '13' Duplicate file. '14' File direction refused. '15' Cipher suite not supported. '16' Encrypted file not allowed. '17' Unencrypted file not allowed. '18' Compression not allowed. '19' Signed file not allowed. '20' Unsigned file not allowed. '21' Invalid file signature. '22' File decryption failure. '23' File decompression failure. '99' Unspecified reason.
值：“01”文件名无效02“目标无效。”03“无效来源”04“不支持存储记录格式。”05“不支持最大记录长度。”06“文件大小太大。”10“无效记录计数”11“无效字节计数”12“访问方法失败”13“重复文件”14“文件方向被拒绝。”15“不支持密码套件。”16“不允许使用加密文件。”17“不允许使用未加密的文件。”18“不允许压缩。”19“不允许使用签名文件。”20“不允许使用未签名的文件。”21“无效的文件签名。”22“文件解密失败。”23“文件解压缩失败”99'未指明原因。
Reason why transmission failed.
传输失败的原因。
EFNAREASL Answer Reason Text Length Numeric(3)
EFNAREASL答案原因文本长度数字（3）
Length in octets of the field EFNAREAST.
字段EFNAREAST的长度（以八位字节为单位）。
0 indicates that no EFNAREAST field follows.
0表示后面没有EFNAREAST字段。
EFNAREAST Answer Reason Text [UTF-8](n)
EFNAREAST应答原因文本[UTF-8]（n）
Reason why transmission failed in plain text.
纯文本传输失败的原因。
It is encoded using [UTF-8].
使用[UTF-8]对其进行编码。
Maximum length of the encoded reason is 999 octets.
编码原因的最大长度为999个八位字节。
No general structure is defined for this attribute.
没有为此属性定义常规结构。
o-------------------------------------------------------------------o
| ESID End Session |
| |
| End Session Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | ESIDCMD | ESID Command, 'F' | F X(1) |
| 1 | ESIDREAS | Reason Code | F 9(2) |
| 3 | ESIDREASL | Reason Text Length | V 9(3) |
| 6 | ESIDREAST | Reason Text | V T(n) |
| | ESIDCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| ESID End Session |
| |
| End Session Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | ESIDCMD | ESID Command, 'F' | F X(1) |
| 1 | ESIDREAS | Reason Code | F 9(2) |
| 3 | ESIDREASL | Reason Text Length | V 9(3) |
| 6 | ESIDREAST | Reason Text | V T(n) |
| | ESIDCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
ESIDCMD Command Code Character
ESIDCMD命令代码字符
Value: 'F' ESID Command identifier.
值：“F”ESID命令标识符。
ESIDREAS Reason Code Numeric(2)
ESIDREAS原因代码数字（2）
Value: '00' Normal session termination
值：“00”正常会话终止
'01' Command not recognised
无法识别“01”命令
An Exchange Buffer contains an invalid command code (1st octet of the buffer).
Exchange缓冲区包含无效的命令代码（缓冲区的第一个八位字节）。
'02' Protocol violation
“02”协议冲突
An Exchange Buffer contains an invalid command for the current state of the receiver.
Exchange缓冲区包含用于接收器当前状态的无效命令。
'03' User code not known
“03”用户代码未知
A Start Session (SSID) command contains an unknown or invalid Identification Code.
启动会话（SSID）命令包含未知或无效的标识码。
'04' Invalid password
“04”密码无效
A Start Session (SSID) command contained an invalid password.
启动会话（SSID）命令包含无效密码。
'05' Local site emergency close down
“05”本地站点紧急关闭
The local site has entered an emergency close down mode. Communications are being forcibly terminated.
本地站点已进入紧急关闭模式。通讯被强行终止。
'06' Command contained invalid data
“06”命令包含无效数据
A field within a Command Exchange Buffer contains invalid data.
命令交换缓冲区中的字段包含无效数据。
'07' Exchange Buffer size error
“07”Exchange缓冲区大小错误
The length of the Exchange Buffer as determined by the Stream Transmission Header differs from the length implied by the Command Code.
由流传输头确定的交换缓冲区长度与命令代码暗示的长度不同。
'08' Resources not available
“08”资源不可用
The request for connection has been denied due to a resource shortage. The connection attempt should be retried later.
由于资源短缺，连接请求已被拒绝。稍后应重试连接尝试。
'09' Time out
“09”暂停
'10' Mode or capabilities incompatible
“10”模式或功能不兼容
'11' Invalid challenge response
“11”无效的质询响应
'12' Secure authentication requirements incompatible
“12”安全身份验证要求不兼容
'99' Unspecified Abort code
“99”未指定的中止代码
An error was detected for which no specific code is defined.
检测到未定义特定代码的错误。
ESIDREASL Reason Text Length Numeric(3)
ESIDREASL原因文本长度数字（3）
Length in octets of the field ESIDREAST.
字段EsidRest的长度（以八位字节为单位）。
0 indicates that no ESIDREAST field is present.
0表示不存在ESIDREAST字段。
ESIDREAST Reason Text [UTF-8](n)
ESIDREAST原因文本[UTF-8]（n）
Reason why session ended in plain text.
会话以纯文本结束的原因。
It is encoded using [UTF-8].
使用[UTF-8]对其进行编码。
Maximum length of the encoded reason is 999 octets.
编码原因的最大长度为999个八位字节。
No general structure is defined for this attribute.
没有为此属性定义常规结构。
ESIDCR Carriage Return Character
ESIDCR回车符
Value: Character with hex value '0D' or '8D'.
值：具有十六进制值“0D”或“8D”的字符。
o-------------------------------------------------------------------o
| CD Change Direction |
| |
| Start File Phase Speaker ----> Listener |
| End File Phase Speaker ----> Listener |
| End Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | CDCMD | CD Command, 'R' | F X(1) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| CD Change Direction |
| |
| Start File Phase Speaker ----> Listener |
| End File Phase Speaker ----> Listener |
| End Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | CDCMD | CD Command, 'R' | F X(1) |
o-------------------------------------------------------------------o
CDCMD Command Code Character
CDCMD命令代码字符
Value: 'R' CD Command identifier.
值：“R”CD命令标识符。
o-------------------------------------------------------------------o
| EERP End to End Response |
| |
| Start File Phase Speaker ----> Listener |
| End File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EERPCMD | EERP Command, 'E' | F X(1) |
| 1 | EERPDSN | Virtual File Dataset Name | V X(26) |
| 27 | EERPRSV1 | Reserved | F X(3) |
| 30 | EERPDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) |
| 38 | EERPTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) |
| 48 | EERPUSER | User Data | V X(8) |
| 56 | EERPDEST | Destination | V X(25) |
| 81 | EERPORIG | Originator | V X(25) |
| 106 | EERPHSHL | Virtual File hash length | V U(2) |
| 108 | EERPHSH | Virtual File hash | V U(n) |
| | EERPSIGL | EERP signature length | V U(2) |
| | EERPSIG | EERP signature | V U(n) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| EERP End to End Response |
| |
| Start File Phase Speaker ----> Listener |
| End File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EERPCMD | EERP Command, 'E' | F X(1) |
| 1 | EERPDSN | Virtual File Dataset Name | V X(26) |
| 27 | EERPRSV1 | Reserved | F X(3) |
| 30 | EERPDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) |
| 38 | EERPTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) |
| 48 | EERPUSER | User Data | V X(8) |
| 56 | EERPDEST | Destination | V X(25) |
| 81 | EERPORIG | Originator | V X(25) |
| 106 | EERPHSHL | Virtual File hash length | V U(2) |
| 108 | EERPHSH | Virtual File hash | V U(n) |
| | EERPSIGL | EERP signature length | V U(2) |
| | EERPSIG | EERP signature | V U(n) |
o-------------------------------------------------------------------o
EERPCMD Command Code Character
EERPCMD命令代码字符
Value: 'E' EERP Command identifier.
值：“E”EERP命令标识符。
EERPDSN Virtual File Dataset Name String(26)
EERPDSN虚拟文件数据集名称字符串（26）
Dataset name of the Virtual File being transferred, assigned by bilateral agreement.
正在传输的虚拟文件的数据集名称，由双边协议指定。
No general structure is defined for this attribute.
没有为此属性定义常规结构。
See Virtual Files - Identification (Section 1.5.2)
见虚拟文件-标识（第1.5.2节）
EERPRSV1 Reserved String(3)
EERPRSV1保留字符串（3）
This field is reserved for future use.
此字段保留供将来使用。
EERPDATE Virtual File Date stamp Numeric(8)
eUpdate虚拟文件日期戳数字（8）
Format: 'CCYYMMDD' 8 decimal digits representing the century, year, month, and day, respectively.
格式：“CCYYMMDD”8位十进制数字，分别表示世纪、年、月和日。
Date stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
由虚拟文件的发起人指定的日期戳，指示文件何时可用于传输。
See Virtual Files - Identification (Section 1.5.2)
见虚拟文件-标识（第1.5.2节）
EERPTIME Virtual File Time stamp Numeric(10)
eOptime虚拟文件时间戳数字（10）
Format: 'HHMMSScccc' 10 decimal digits representing hours, minutes, seconds, and a counter (0001-9999), which gives higher resolution.
格式：“HHMMSScccc”10位十进制数字，代表小时、分钟、秒和计数器（0001-9999），可提供更高的分辨率。
Time stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
由虚拟文件的发起人指定的时间戳，指示文件何时可用于传输。
See Virtual Files - Identification (Section 1.5.2)
见虚拟文件-标识（第1.5.2节）
EERPUSER User Data String(8)
EERPUSER用户数据字符串（8）
May be used by ODETTE-FTP in any way. If unused, it should be initialised to spaces. It is expected that a bilateral agreement exists as to the meaning of the data.
可由ODETTE-FTP以任何方式使用。如果未使用，则应将其初始化为空格。预计将就数据的含义达成双边协议。
EERPDEST Destination String(25)
EERPDEST目标字符串（25）
Format: See Identification Code (Section 5.4)
格式：见识别码（第5.4节）
Originator of the Virtual File.
虚拟文件的发起人。
This is the location that created the data for transmission.
这是为传输创建数据的位置。
EERPORIG Originator String(25)
EERPORIG发起者字符串（25）
Format: See Identification Code (Section 5.4)
格式：见识别码（第5.4节）
Final Recipient of the Virtual File.
虚拟文件的最终收件人。
This is the location that will look into the Virtual File content and process it accordingly. It is also the location that creates the EERP for the received file.
这是查看虚拟文件内容并进行相应处理的位置。它也是为接收的文件创建EERP的位置。
EERPHSHL Virtual File hash length Binary(2)
EERPHSHL虚拟文件哈希长度二进制文件（2）
Length in octets of the field EERPHSH.
字段EERPHSH的长度（以八位字节为单位）。
A binary value of 0 indicates that no hash is present. This is always the case if the EERP is not signed.
二进制值0表示不存在哈希。如果未签署EERP，则情况始终如此。
EERPHSH Virtual File hash Binary(n)
EERPHSH虚拟文件哈希二进制（n）
Hash of the transmitted Virtual File, i.e., not the hash of the original file.
传输的虚拟文件的散列，即，不是原始文件的散列。
The algorithm used is determined by the bilaterally agreed cipher suite specified in the SFIDCIPH.
使用的算法由SFIDCIPH中规定的双边约定密码套件确定。
It is an application implementation issue to validate the EERPHSH to ensure that the EERP is acknowledging the exact same file as was originally transmitted.
验证EERPHSH以确保EERP确认的文件与最初传输的文件完全相同，这是一个应用程序实现问题。
EERPSIGL EERP signature length Binary(2)
EERPSIGL EERP签名长度二进制（2）
0 indicates that this EERP has not been signed.
0表示此EERP尚未签名。
Any other value indicates the length of EERPSIG in octets and indicates that this EERP has been signed.
任何其他值表示EERPIG的长度（以八位字节为单位），并表示该EERP已签名。
EERPSIG EERP signature Binary(n)
EERP签名二进制（n）
Contains the [CMS] enveloped signature of the EERP.
包含EERP的[CMS]信封签名。
Signature = Sign{EERPDSN EERPDATE EERPTIME EERPDEST EERPORIG EERPHSH}
签名=签名{EERPDSN EERPDATE EERPTIME EERPDEST EERPORIG EERPHSH}
Each field is taken in its entirety, including any padding. The envelope must contain the original data, not just the signature.
每个字段都是完整的，包括任何填充。信封必须包含原始数据，而不仅仅是签名。
The [CMS] content type used is SignedData.
使用的[CMS]内容类型为SignedData。
The encapsulated content type used is id-data.
使用的封装内容类型是id数据。
It is an application issue to validate the signature with the contents of the EERP.
验证带有EERP内容的签名是一个应用程序问题。
o-------------------------------------------------------------------o
| NERP Negative End Response |
| |
| Start File Phase Speaker ----> Listener |
| End File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | NERPCMD | NERP Command, 'N' | F X(1) |
| 1 | NERPDSN | Virtual File Dataset Name | V X(26) |
| 27 | NERPRSV1 | Reserved | F X(6) |
| 33 | NERPDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) |
| 41 | NERPTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) |
| 51 | NERPDEST | Destination | V X(25) |
| 76 | NERPORIG | Originator | V X(25) |
| 101 | NERPCREA | Creator of NERP | V X(25) |
| 126 | NERPREAS | Reason code | F 9(2) |
| 128 | NERPREASL | Reason text length | V 9(3) |
| 131 | NERPREAST | Reason text | V T(n) |
| | NERPHSHL | Virtual File hash length | V U(2) |
| | NERPHSH | Virtual File hash | V U(n) |
| | NERPSIGL | NERP signature length | V U(2) |
| | NERPSIG | NERP signature | V U(n) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| NERP Negative End Response |
| |
| Start File Phase Speaker ----> Listener |
| End File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | NERPCMD | NERP Command, 'N' | F X(1) |
| 1 | NERPDSN | Virtual File Dataset Name | V X(26) |
| 27 | NERPRSV1 | Reserved | F X(6) |
| 33 | NERPDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) |
| 41 | NERPTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) |
| 51 | NERPDEST | Destination | V X(25) |
| 76 | NERPORIG | Originator | V X(25) |
| 101 | NERPCREA | Creator of NERP | V X(25) |
| 126 | NERPREAS | Reason code | F 9(2) |
| 128 | NERPREASL | Reason text length | V 9(3) |
| 131 | NERPREAST | Reason text | V T(n) |
| | NERPHSHL | Virtual File hash length | V U(2) |
| | NERPHSH | Virtual File hash | V U(n) |
| | NERPSIGL | NERP signature length | V U(2) |
| | NERPSIG | NERP signature | V U(n) |
o-------------------------------------------------------------------o
NERPCMD Command Code Character
NERPCMD命令代码字符
Value: 'N' NERP Command identifier.
值：“N”NERP命令标识符。
NERPDSN Virtual File Dataset Name String(26)
NERPDSN虚拟文件数据集名称字符串（26）
Dataset name of the Virtual File being transferred, assigned by bilateral agreement.
正在传输的虚拟文件的数据集名称，由双边协议指定。
No general structure is defined for this attribute.
没有为此属性定义常规结构。
See Virtual Files - Identification (Section 1.5.2)
见虚拟文件-标识（第1.5.2节）
NERPRSV1 Reserved String(6)
NERPRSV1保留字符串（6）
This field is reserved for future use.
此字段保留供将来使用。
NERPDATE Virtual File Date stamp Numeric(8)
neUpdate虚拟文件日期戳数字（8）
Format: 'CCYYMMDD' 8 decimal digits representing the century, year, month, and day, respectively.
格式：“CCYYMMDD”8位十进制数字，分别表示世纪、年、月和日。
Date stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
由虚拟文件的发起人指定的日期戳，指示文件何时可用于传输。
See Virtual Files - Identification (Section 1.5.2)
见虚拟文件-标识（第1.5.2节）
NERPTIME Virtual File Time stamp Numeric(10)
NERPTIME虚拟文件时间戳数字（10）
Format: 'HHMMSScccc' 10 decimal digits representing hours, minutes, seconds, and a counter (0001-9999), which gives higher resolution.
格式：“HHMMSScccc”10位十进制数字，代表小时、分钟、秒和计数器（0001-9999），可提供更高的分辨率。
Time stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
由虚拟文件的发起人指定的时间戳，指示文件何时可用于传输。
See Virtual Files - Identification (Section 1.5.2)
见虚拟文件-标识（第1.5.2节）
NERPDEST Destination String(25)
NERPDEST目标字符串（25）
Format: See Identification Code (Section 5.4)
格式：见识别码（第5.4节）
Originator of the Virtual File.
虚拟文件的发起人。
This is the location that created the data for transmission.
这是为传输创建数据的位置。
NERPORIG Originator String(25)
NERPORIG发起者字符串（25）
Format: See Identification Code (Section 5.4)
格式：见识别码（第5.4节）
The Final Recipient of the Virtual File.
虚拟文件的最终收件人。
This is the location that will look into the Virtual File content and perform mapping functions.
这是查看虚拟文件内容并执行映射功能的位置。
NERPCREA Creator of the NERP String(25)
NERPCREA NERP字符串的创建者（25）
Format: See Identification Code (Section 5.4)
格式：见识别码（第5.4节）
It is the location that created the NERP.
这是创建NERP的位置。
NERPREAS Reason code Numeric(2)
NERPREAS原因代码数字（2）
This attribute will specify why transmission cannot proceed or why processing of the file failed.
此属性将指定传输无法继续或文件处理失败的原因。
"SFNA(RETRY=N)" below should be interpreted as "EFNA or SFNA(RETRY=N)" where appropriate.
在适当情况下，下面的“SFNA（重试=N）”应解释为“EFNA或SFNA（重试=N）”。
Value '03' ESID received with reason code '03' (user code not known) '04' ESID received with reason code '04' (invalid password) '09' ESID received with reason code '99' (unspecified reason) '11' SFNA(RETRY=N) received with reason code '01' (invalid file name) '12' SFNA(RETRY=N) received with reason code '02' (invalid destination) '13' SFNA(RETRY=N) received with reason code '03' (invalid origin) '14' SFNA(RETRY=N) received with reason code '04' (invalid storage record format) '15' SFNA(RETRY=N) received with reason code '05' (maximum record length not supported) '16' SFNA(RETRY=N) received with reason code '06' (file size too big) '20' SFNA(RETRY=N) received with reason code '10' (invalid record count) '21' SFNA(RETRY=N) received with reason code '11' (invalid byte count) '22' SFNA(RETRY=N) received with reason code '12' (access method failure)
接收到的值“03”ESID的原因代码为“03”（用户代码未知）“04”ESID的原因代码为“04”（无效密码）“09”ESID的原因代码为“99”（未指定原因）“11”SFNA（重试=N）的原因代码为“01”（无效文件名）“12”SFNA（重试=N）的原因代码为“02”（无效目标）“13”SFNA（重试=N）接收的原因代码为“03”（无效来源）'14'SFNA（重试=N）接收的原因代码为“04”（无效存储记录格式）'15'SFNA（重试=N）接收的原因代码为“05”（不支持最大记录长度）'16'SFNA（重试=N）接收的原因代码为“06”（文件大小太大）'20'SFNA（重试=N）接收的原因代码为“10”（无效记录计数）'21'SFNA（重试=N）接收到的原因码为'11'（无效字节计数）'22'SFNA（重试=N）接收到的原因码为'12'（访问方法失败）
'23' SFNA(RETRY=N) received with reason code '13' (duplicate file) '24' SFNA(RETRY=N) received with reason code '14' (file direction refused) '25' SFNA(RETRY=N) received with reason code '15' (cipher suite not supported) '26' SFNA(RETRY=N) received with reason code '16' (encrypted file not allowed) '27' SFNA(RETRY=N) received with reason code '17' (unencrypted file not allowed) '28' SFNA(RETRY=N) received with reason code '18' (compression not allowed) '29' SFNA(RETRY=N) received with reason code '19' (signed file not allowed) '30' SFNA(RETRY=N) received with reason code '20' (unsigned file not allowed) '31' File signature not valid. '32' File decompression failed. '33' File decryption failed. '34' File processing failed. '35' Not delivered to recipient. '36' Not acknowledged by recipient. '50' Transmission stopped by the operator. '90' File size incompatible with recipient's protocol version. '99' Unspecified reason.
“23”SFNA（重试=N）接收的原因码为“13”（重复文件）“24”SFNA（重试=N）接收的原因码为“14”（文件方向被拒绝）“25”SFNA（重试=N）接收的原因码为“15”（不支持密码套件）“26”SFNA（重试=N）接收的原因码为“16”（不允许加密文件）“27”SFNA（重试=N）接收的原因代码为“17”（不允许未加密文件）'28'SFNA（重试=N）接收的原因代码为“18”（不允许压缩）'29'SFNA（重试=N）接收的原因代码为“19”（不允许签名文件）'30'SFNA（重试=N）接收的原因代码为“20”（不允许未签名文件）'31'文件签名无效。'32“文件解压缩失败。”33“文件解密失败。”34“文件处理失败。”35“未送达收件人”36“收件人未确认”50‘操作员停止了变速箱。’90“文件大小与收件人的协议版本不兼容。”99'未指明原因。
NERPREASL Reason Text Length Numeric(3)
NERPRESAL原因文本长度数字（3）
Length in octets of the field NERPREAST.
字段nerprest的长度（以八位字节为单位）。
0 indicates that no NERPREAST field follows.
0表示后面没有nerprest字段。
NERPREAST Reason Text [UTF-8](n)
NERPEAST原因文本[UTF-8]（n）
Reason why transmission cannot proceed in plain text.
无法以纯文本进行传输的原因。
It is encoded using [UTF-8].
使用[UTF-8]对其进行编码。
Maximum length of the encoded reason is 999 octets.
编码原因的最大长度为999个八位字节。
No general structure is defined for this attribute.
没有为此属性定义常规结构。
NERPHSHL Virtual File hash length Binary(2)
NERPHSHL虚拟文件哈希长度二进制文件（2）
Length in octets of the field NERPHSH.
字段NERPHSH的长度（以八位字节为单位）。
A binary value of 0 indicates that no hash is present. This is always the case if the NERP is not signed.
二进制值0表示不存在哈希。如果没有签署NERP，情况总是如此。
NERPHSH Virtual File hash Binary(n)
NERPHSH虚拟文件哈希二进制（n）
Hash of the Virtual File being transmitted.
正在传输的虚拟文件的哈希。
The algorithm used is determined by the bilaterally agreed cipher suite specified in the SFIDCIPH.
使用的算法由SFIDCIPH中规定的双边约定密码套件确定。
NERPSIGL NERP Signature length Binary(2)
NERPSIGL NERP签名长度二进制（2）
0 indicates that this NERP has not been signed.
0表示此NERP尚未签名。
Any other value indicates the length of NERPSIG in octets and indicates that this NERP has been signed.
任何其他值表示以八位字节为单位的NERPIG长度，并表示该NERP已签署。
NERPSIG NERP Signature Binary(n)
NERP签名二进制（n）
Contains the [CMS] enveloped signature of the NERP.
包含NERP的[CMS]信封签名。
Signature = Sign{NERPDSN NERPDATE NERPTIME NERPDEST NERPORIG NERPCREA NERPHSH}
签名=签名{NERPDSN NERPDATE NERPTIME NERPDEST NERPORIG NERPCREA NERPHSH}
Each field is taken in its entirety, including any padding. The envelope must contain the original data, not just the signature.
每个字段都是完整的，包括任何填充。信封必须包含原始数据，而不仅仅是签名。
The [CMS] content type used is SignedData.
使用的[CMS]内容类型为SignedData。
The encapsulated content type used is id-data.
使用的封装内容类型是id数据。
It is an application issue to validate the signature with the contents of the NERP.
使用NERP的内容验证签名是一个应用程序问题。
o-------------------------------------------------------------------o
| RTR Ready To Receive |
| |
| Start File Phase Initiator <---- Responder |
| End File Phase Initiator <---- Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | RTRCMD | RTR Command, 'P' | F X(1) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| RTR Ready To Receive |
| |
| Start File Phase Initiator <---- Responder |
| End File Phase Initiator <---- Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | RTRCMD | RTR Command, 'P' | F X(1) |
o-------------------------------------------------------------------o
RTRCMD Command Code Character
RTRCMD命令代码字符
Value: 'P' RTR Command identifier.
值：“P”RTR命令标识符。
o-------------------------------------------------------------------o
| SECD Security Change Direction |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SECDCMD | SECD Command, 'J' | F X(1) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| SECD Security Change Direction |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SECDCMD | SECD Command, 'J' | F X(1) |
o-------------------------------------------------------------------o
SECDCMD Command Code Character
SECDCMD命令代码字符
Value: 'J' SECD Command identifier.
值：“J”SECD命令标识符。
o-------------------------------------------------------------------o
| AUCH Authentication Challenge |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | AUCHCMD | AUCH Command, 'A' | F X(1) |
| 1 | AUCHCHLL | Challenge Length | V U(2) |
| 3 | AUCHCHAL | Challenge | V U(n) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| AUCH Authentication Challenge |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | AUCHCMD | AUCH Command, 'A' | F X(1) |
| 1 | AUCHCHLL | Challenge Length | V U(2) |
| 3 | AUCHCHAL | Challenge | V U(n) |
o-------------------------------------------------------------------o
AUCHCMD Command Code Character
AUCHCMD命令代码字符
Value: 'A' AUCH Command identifier.
值：“A”AUCH命令标识符。
AUCHCHLL Challenge length Binary(2)
AUCHCHLL质询长度二进制（2）
Indicates the length of AUCHCHAL in octets.
表示AUCHCHAL的长度（以八位字节为单位）。
The length is expressed as an unsigned binary number using network byte order.
长度使用网络字节顺序表示为无符号二进制数。
AUCHCHAL Challenge Binary(n)
AUCHCHAL挑战二进制（n）
A [CMS] encrypted 20-byte random number uniquely generated each time an AUCH is sent.
每次发送AUCH时唯一生成的[CMS]加密的20字节随机数。
NOTE:
注:
Any encryption algorithm that is available through a defined cipher suite (Section 10.2) may be used. See Section 10.1 regarding the choice of a cipher suite.
可以使用通过定义的密码套件（第10.2节）提供的任何加密算法。关于密码套件的选择，请参见第10.1节。
o-------------------------------------------------------------------o
| AURP Authentication Response |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | AURPCMD | AURP Command, 'S' | F X(1) |
| 1 | AURPRSP | Response | V U(20) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| AURP Authentication Response |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | AURPCMD | AURP Command, 'S' | F X(1) |
| 1 | AURPRSP | Response | V U(20) |
o-------------------------------------------------------------------o
AURPCMD Command Code Character
AURPCMD命令代码字符
Value: 'S' AURP Command identifier.
值：“S”AURP命令标识符。
AURPRSP Response Binary(20)
AURPRP响应二进制文件（20）
Contains the decrypted challenge (AUCHCHAL).
包含已解密的质询（AUCHCHAL）。
IMPORTANT:
重要：
It is an application implementation issue to validate a received AURP to ensure that the response matches the challenge. This validation is extremely important to ensure that a party is correctly authenticated.
验证收到的AURP以确保响应与质询匹配是应用程序实现的问题。此验证对于确保正确验证一方极为重要。
The Initiator (sender) and Responder (receiver) participating in an ODETTE-FTP session are uniquely identified by an Identification Code based on [ISO-6523], Structure for the Identification of Organisations (SIO). The locations are considered to be adjacent for the duration of the transmission.
参与ODETTE-FTP会话的发起者（发送者）和响应者（接收者）通过基于[ISO-6523]的标识码进行唯一标识，该标识码用于组织标识（SIO）。在传输期间，这些位置被认为是相邻的。
The SIO has the following format.
SIO具有以下格式。
o-------------------------------------------------------------------o
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SIOOID | ODETTE Identifier | F X(1) |
| 1 | SIOICD | International Code Designator | V 9(4) |
| 5 | SIOORG | Organisation Code | V X(14) |
| 19 | SIOCSA | Computer Subaddress | V X(6) |
o-------------------------------------------------------------------o
o-------------------------------------------------------------------o
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SIOOID | ODETTE Identifier | F X(1) |
| 1 | SIOICD | International Code Designator | V 9(4) |
| 5 | SIOORG | Organisation Code | V X(14) |
| 19 | SIOCSA | Computer Subaddress | V X(6) |
o-------------------------------------------------------------------o
SIOOID ODETTE Identifier Character
SIOOID-ODETTE标识符字符
Value: 'O' Indicates ODETTE assigned Organisation Identifier. Other values may be used for non-ODETTE codes.
值：“O”表示ODETTE分配的组织标识符。其他值可用于非ODETTE代码。
SIOICD International Code Designator String(4)
SIOICD国际代码指示符字符串（4）
A code forming part of the Organisation Identifier.
构成组织标识符一部分的代码。
SIOORG Organisation Code String(14)
组织机构代码字符串（14）
A code forming part of the Organisation Identifier. This field may contain the letters A to Z, the digits 0 to 9, and space and hyphen characters.
构成组织标识符一部分的代码。此字段可能包含字母A到Z、数字0到9以及空格和连字符。
SIOCSA Computer Subaddress String(6)
SIOCSA计算机子地址字符串（6）
A locally assigned address that uniquely identifies a system within an organisation (defined by an Organisation Identifier).
本地分配的地址，唯一标识组织内的系统（由组织标识符定义）。
ODETTE-FTP provides services for compressing, encrypting, and signing files. These services should generally be performed off line, outside of the ODETTE-FTP communications session for performance reasons, although this is not a strict requirement.
ODETTE-FTP提供压缩、加密和签名文件的服务。出于性能原因，这些服务通常应在ODETTE-FTP通信会话之外离线执行，尽管这不是严格要求。
ODETTE-FTP requires that the following steps must be performed in this exact sequence, although any of steps 2, 3, or 4 may be omitted. Step 1 is required only if any of steps 2, 3, or 4 are performed:
ODETTE-FTP要求以下步骤必须按此确切顺序执行，尽管步骤2、3或4中的任何一个都可以省略。仅当执行步骤2、3或4中的任何一个时，才需要步骤1：
1. Insert record length indicators (V format files only; see Section 6.5) 2. Sign 3. Compress 4. Encrypt
1. 插入记录长度指示器（仅V格式文件；参见第6.5节）2。标志3。压缩4。加密
The cipher suite for the encryption and signing algorithms is assigned by bilateral agreement.
加密和签名算法的密码套件由双边协议分配。
Secured and/or compressed files must be enveloped. The envelope contains additional information about the service used that is necessary for a receiving party to fully process the file.
必须封装安全和/或压缩文件。信封包含接收方完整处理文件所需的有关所用服务的附加信息。
The [CMS] content types used are:
使用的[CMS]内容类型有：
EnvelopedData - Indicates encrypted data CompressedData - Indicates compressed data SignedData - Indicates signed content Data - Indicates unstructured data
信封数据-表示加密数据压缩数据-表示压缩数据签名数据-表示签名内容数据-表示非结构化数据
For signed or encrypted data, the encapsulated content type (eContentType field) is id-data.
对于签名或加密数据，封装的内容类型（eContentType字段）是id数据。
Files that are to be signed are enveloped according to the file enveloping format (SFIDENV). Generally, this will be as a [CMS] package.
要签名的文件根据文件封装格式（SFIDENV）进行封装。通常，这将作为一个[CMS]包。
A file may be signed more than once to ease the changeover between old and new certificates.
一个文件可以多次签名，以简化新旧证书之间的转换。
It is recommended that the envelope does not contain the public certificate of the signer. Where files are sent to the same recipient continuously, it would serve no benefit to repeatedly send the same certificate. Both the original file data and signature are stored within the [CMS] package.
建议信封中不要包含签名人的公共证书。如果文件连续发送给同一个收件人，则重复发送同一证书没有任何好处。原始文件数据和签名都存储在[CMS]包中。
Files that are to be encrypted are enveloped according to the file enveloping format (SFIDENV). Generally, this will be as a [CMS] package.
要加密的文件根据文件封装格式（SFIDENV）进行封装。通常，这将作为一个[CMS]包。
It is recommended that encryption should be performed before the ODETTE-FTP session starts because a large file takes a long time to encrypt and could cause session time outs, even on high-performance machines.
建议在ODETTE-FTP会话开始之前执行加密，因为大型文件加密需要很长时间，甚至在高性能计算机上也可能导致会话超时。
Likewise, decryption of the file should occur outside of the session. However, an application may choose to allow in-session encryption and decryption for very small files.
同样，文件的解密应该在会话之外进行。但是，应用程序可以选择允许对非常小的文件进行会话内加密和解密。
Files that are to be compressed are enveloped according to the file enveloping format (SFIDENV). Generally, this will be as a [CMS] package using the [CMS-Compression] data type, which uses the [ZLIB] compression algorithm by default.
要压缩的文件根据文件封装格式（SFIDENV）进行封装。通常，这将作为使用[CMS Compression]数据类型的[CMS]包，默认情况下使用[ZLIB]压缩算法。
Unlike the buffer compression method, this method operates on a whole file. Because of the increased levels of compression, file level compression essentially deprecates the older buffer compression inside ODETTE-FTP. The buffer compression is kept for backwards compatibility.
与缓冲区压缩方法不同，此方法对整个文件进行操作。由于压缩级别的提高，文件级压缩基本上不支持ODETTE-FTP中较旧的缓冲区压缩。保留缓冲区压缩是为了向后兼容。
A file that has been signed, compressed, and/or encrypted will have lost its record structure, so ODETTE-FTP will not be able to insert the End of Record Flag in subrecord headers in Data Exchange Buffers. To preserve the record structure, V format files must have record headers inserted into them prior to signing, compression, or encryption. These 2-byte binary numbers, in network byte order, indicate the length of each record, allowing the receiving system, where appropriate, to recreate the files complete with the original variable-length records. Note that the header bytes hold the number of data bytes in the record and don't include themselves.
已签名、压缩和/或加密的文件将丢失其记录结构，因此ODETTE-FTP将无法在数据交换缓冲区的子记录头中插入记录结束标志。为了保留记录结构，V格式文件必须在签名、压缩或加密之前插入记录头。这些2字节二进制数（按网络字节顺序）表示每条记录的长度，允许接收系统在适当情况下重新创建包含原始可变长度记录的文件。请注意，头字节包含记录中的数据字节数，不包括它们自己。
This is only applicable to V format files, which themselves are typically only of concern for mainframes.
这仅适用于V格式文件，而V格式文件本身通常只与大型机有关。
Virtual Files are transmitted by mapping the Virtual File records into Data Exchange Buffers, the maximum length of which was negotiated between the ODETTE-FTP entities via the Start Session (SSID) commands exchanged during the Start Session phase of the protocol.
通过将虚拟文件记录映射到数据交换缓冲区来传输虚拟文件，数据交换缓冲区的最大长度由ODETTE-FTP实体通过在协议的启动会话阶段交换的启动会话（SSID）命令协商确定。
Virtual File records may be of arbitrary length. A simple compression scheme is defined for strings of repeated characters.
虚拟文件记录可以是任意长度。为重复字符的字符串定义了一个简单的压缩方案。
An example of the use of the Data Exchange Buffer can be found in Appendix A.
数据交换缓冲区的使用示例见附录A。
For transmission of Virtual File records, data is divided into subrecords, each of which is preceded by a 1-octet Subrecord Header.
对于虚拟文件记录的传输，数据被划分为子记录，每个子记录前面都有一个1-octet子记录头。
The Data Exchange Buffer is made up of the initial Command Character followed by pairs of Subrecord Headers and subrecords, as follows.
数据交换缓冲区由初始命令字符和成对的子记录头和子记录组成，如下所示。
o--------------------------------------------------------
| C | H | | H | | H | | /
| M | D | SUBRECORD | D | SUBRECORD | D | SUBRECORD | /_
| D | R | | R | | R | | /
o-------------------------------------------------------
o--------------------------------------------------------
| C | H | | H | | H | | /
| M | D | SUBRECORD | D | SUBRECORD | D | SUBRECORD | /_
| D | R | | R | | R | | /
o-------------------------------------------------------
CMD
指令
The Data Exchange Buffer Command Character, 'D'.
数据交换缓冲区命令字符“D”。
HDR
HDR
A 1-octet Subrecord Header defined as follows:
定义如下的1-octet子记录头：
0 1 2 3 4 5 6 7
o-------------------------------o
| E | C | |
| o | F | C O U N T |
| R | | |
o-------------------------------o
0 1 2 3 4 5 6 7
o-------------------------------o
| E | C | |
| o | F | C O U N T |
| R | | |
o-------------------------------o
Bits
位
0 End of Record Flag
0记录结束标志
Set to indicate that the next subrecord is the last subrecord of the current record.
设置以指示下一个子记录是当前记录的最后一个子记录。
Unstructured files are transmitted as a single record; in this case, the flag acts as an end-of-file marker.
非结构化文件作为单个记录传输；在这种情况下，该标志充当文件结束标记。
1 Compression Flag
1压缩标志
Set to indicate that the next subrecord is compressed.
设置以指示下一个子记录已压缩。
2-7 Subrecord Count
2-7子记录计数
The number of octets in the Virtual File represented by the next subrecord expressed as a binary value.
虚拟文件中的八位字节数，由下一个子记录表示为二进制值。
For uncompressed data, this is simply the length of the subrecord.
对于未压缩的数据，这只是子记录的长度。
For compressed data, this is the number of times that the single octet in the following subrecord must be inserted in the Virtual File.
对于压缩数据，这是必须将以下子记录中的单个八位字节插入虚拟文件的次数。
As 6 bits are available, the next subrecord may represent between 0 and 63 octets of the Virtual File.
由于有6位可用，下一个子记录可能表示虚拟文件的0到63个八位字节。
A Data Exchange Buffer may be any length up to the value negotiated in the Start Session exchange.
数据交换缓冲区的长度可以是在开始会话交换中协商的值之前的任意长度。
Virtual File records may be concatenated within one Data Exchange Buffer or split across a number of buffers.
虚拟文件记录可以连接在一个数据交换缓冲区内，也可以跨多个缓冲区拆分。
A subrecord is never split between two Exchange Buffers. If the remaining space in the current Exchange Buffer is insufficient to contain the next 'complete' subrecord, one of the following strategies should be used:
子记录永远不会在两个Exchange缓冲区之间分割。如果当前Exchange缓冲区中的剩余空间不足以容纳下一个“完整”子记录，则应使用以下策略之一：
1. Truncate the Exchange Buffer, and put the complete subrecord (preceded by its header octet) in a new Exchange Buffer.
1. 截断Exchange缓冲区，并将完整的子记录（前面有其头八位字节）放入新的Exchange缓冲区。
2. Split the subrecord into two, filling the remainder of the Exchange Buffer with the first new subrecord and starting a new Exchange Buffer with the second.
2. 将子记录一分为二，用第一个新的子记录填充Exchange缓冲区的其余部分，并用第二个新的子记录启动新的Exchange缓冲区。
A record of length zero may appear anywhere in the Exchange Buffer.
长度为零的记录可能出现在Exchange缓冲区中的任何位置。
A subrecord of length zero may appear anywhere in the record and/or the Exchange Buffer.
长度为零的子记录可能出现在记录和/或Exchange缓冲区中的任何位置。
To utilise the TCP stream, a Stream Transmission Buffer (STB) is created by adding a Stream Transmission Header (STH) to the start of all Command and Data Exchange Buffers before they are passed to the TCP transport service. This allows the receiving ODETTE-FTP to recover the original Exchange Buffers.
为了利用TCP流，在将所有命令和数据交换缓冲区传递到TCP传输服务之前，通过在所有命令和数据交换缓冲区的开头添加流传输头（STH）来创建流传输缓冲区（STB）。这允许接收ODETTE-FTP恢复原始Exchange缓冲区。
Note: The Stream Transmission Buffer is not used when using ODETTE-FTP over an X.25 network.
注意：在X.25网络上使用ODETTE-FTP时，不使用流传输缓冲区。
This is because ODETTE-FTP can rely on the fact that the Network Service will preserve the sequence and boundaries of data units transmitted through the network and that the Network Service will pass the length of the data unit to the receiving ODETTE-FTP. TCP offers a stream-based connection that does not provide these functions.
这是因为ODETTE-FTP可以依赖这样一个事实，即网络服务将保留通过网络传输的数据单元的顺序和边界，并且网络服务将数据单元的长度传递给接收ODETTE-FTP。TCP提供的基于流的连接不提供这些功能。
The Stream Transmission Buffer is composed of an STH and an OEB.
流传输缓冲器由STH和OEB组成。
o-----+-----------------+-----+--------------------+-----+------
| STH | OEB | STH | OEB | STH | OEB/
o-----+-----------------+-----+--------------------+-----+----
o-----+-----------------+-----+--------------------+-----+------
| STH | OEB | STH | OEB | STH | OEB/
o-----+-----------------+-----+--------------------+-----+----
STH - Stream Transmission Header OEB - ODETTE-FTP Exchange Buffer
STH-流传输头OEB-ODETE-FTP交换缓冲区
The Stream Transmission Header is shown below. The fields are transmitted from left to right.
流传输头如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
版本
Value: 0001 (binary)
值：0001（二进制）
Stream Transmission Header version number.
流传输头版本号。
Flags
旗帜
Value: 0000 (binary)
值：0000（二进制）
Reserved for future use.
保留供将来使用。
Length
长
Range: 5 - 100003 (decimal)
范围：5-100003（十进制）
The length of the Stream Transmission Buffer (STH+OEB).
流传输缓冲区的长度（STH+OEB）。
The smallest STB is 5 octets consisting of a 4-octet header followed by a 1-octet Exchange Buffer such as a Change Direction (CD) command.
最小的STB是5个八位字节，由4个八位字节的报头和1个八位字节的交换缓冲区（如更改方向（CD）命令）组成。
The maximum Exchange Buffer length that can be negotiated is 99999 octets (Section 5.3.2) giving an STB length of 100003.
可协商的最大交换缓冲区长度为99999个八位字节（第5.3.2节），STB长度为100003。
The length is expressed as a binary number in network byte order.
长度以网络字节顺序表示为二进制数。
It is expected that implementations of this protocol will follow the Internet robustness principle of being conservative in what is sent and liberal in what is accepted.
预计该协议的实现将遵循互联网健壮性原则，即发送内容保守，接受内容自由。
The operation of an ODETTE-FTP entity is formally defined by the State Machine presented below. There are five State and Transition tables, and for each table additional information is given in the associated Predicate and Action lists.
ODETTE-FTP实体的操作由下面的状态机正式定义。有五个状态表和转换表，每个表的附加信息在相关谓词和操作列表中给出。
The response of an ODETTE-FTP entity to the receipt of an event is defined by a Transition table entry indexed by the Event/State intersection within the appropriate state table.
ODETTE-FTP实体对事件接收的响应由相应状态表中的事件/状态交叉点索引的转换表条目定义。
Each Transition table entry defines the actions taken, events generated, and new state entered. Predicates may be used within a table entry to select the correct response on the basis of local information held by the entity.
每个转换表条目定义所采取的操作、生成的事件和输入的新状态。谓词可以在表条目中使用，以根据实体持有的本地信息选择正确的响应。
A Transition table contains the following fields:
转换表包含以下字段：
Index (I) State transition index.
索引（I）状态转换索引。
Predicate A list of predicates used to select between different possible transitions. The predicates are defined in the Predicate and Action lists.
谓词用于在不同可能的转换之间进行选择的谓词列表。谓词在谓词和操作列表中定义。
Actions A list of actions taken by the entity. The actions are defined in the Predicate and Action lists.
操作实体采取的操作的列表。动作在谓词和动作列表中定义。
Events Output events generated by the entity.
事件输出实体生成的事件。
Next State The new state of the entity.
下一个状态实体的新状态。
The receipt of an event in a given state may be invalid for three reasons.
在给定状态下接收事件可能无效，原因有三。
1. The case is impossible by design of the state automata, denoted 'X' in the state tables. For example, a timer that has not been set cannot run out.
1. 通过状态自动机的设计，这种情况是不可能的，在状态表中表示为“X”。例如，未设置的计时器无法运行。
2. The event is the result of an error in the Network Service implementation, also denoted 'X' in the state tables. The Network Service implementation is considered to be correct.
2. 该事件是网络服务实现中的错误导致的，在状态表中也表示为“X”。网络服务实现被认为是正确的。
3. For all other cases, the event is considered to be a User Error, denoted "U" in the state tables.
3. 对于所有其他情况，该事件被视为用户错误，在状态表中表示为“U”。
The state tables define the conditions under which a User event is valid, thus preventing the generation of a protocol error by the ODETTE-FTP entity as a result of a User Monitor error. The reaction of the entity to such errors is undefined and regarded as a local implementation issue.
状态表定义了用户事件有效的条件，从而防止ODETTE-FTP实体因用户监视器错误而生成协议错误。实体对此类错误的反应未定义，并被视为本地实现问题。
The state tables also allow protocol errors due to the receipt of invalid Exchange Buffers, to be detected. In such cases, the reaction of the entity to the error is defined.
状态表还允许检测由于接收到无效的Exchange缓冲区而导致的协议错误。在这种情况下，定义实体对错误的反应。
The Command Mode is strictly a half-duplex flip-flop mode.
命令模式严格地说是半双工触发器模式。
A_NC_ONLY Responder, Network Connection opened
仅限NC的响应程序，网络连接已打开
The Responder has sent its Ready Message (SSRM) and is waiting for Start Session (SSID) from the Initiator.
响应程序已发送其就绪消息（SSRM），正在等待发起程序的启动会话（SSID）。
A_WF_CONRS Responder Waiting for F_CONNECT_RS
正在等待F\u连接的\u WF\u CONRS响应程序
The Responder has received the Initiator's Start Session (SSID) and is waiting for a response (F_CONNECT_RS) from its User Monitor.
响应程序已收到启动器的启动会话（SSID），正在等待来自其用户监视器的响应（F_CONNECT_RS）。
CDSTWFCD CD_RQ stored in WF_CD state
CDSTWFCD CD_RQ存储在WF_CD状态
Since the User Monitor doesn't see the WF_CD state, it may send a Change Direction request (F_CD_RQ) before the ODETTE-FTP receives a Change Direction (CD) command.
由于用户监视器看不到WF_CD状态，它可能会在ODETTE-FTP收到更改方向（CD）命令之前发送更改方向请求（F_CD_RQ）。
CLIP Close Input Pending
剪辑关闭输入挂起
The Listener has received an End File (EFID) command and is waiting for the Close File response (F_CLOSE_FILE_RS) from its User Monitor.
侦听器已收到结束文件（EFID）命令，正在等待来自其用户监视器的关闭文件响应（F_Close_File_RS）。
CLOP Close Out Pending
CLOP关闭待定
The Speaker has sent an End File (EFID) command and is waiting for an End File Answer (EFPA or EFNA).
扬声器已发送结束文件（EFID）命令，正在等待结束文件应答（EFPA或EFNA）。
ERSTWFCD End to End Response stored in WF_CD state
ERSTWFCD端到端响应存储在WF_CD状态
Since the User Monitor doesn't see the WF_CD state, it may send F_EERP_RQ, before ODETTE-FTP receives a Change Direction (CD) command.
由于用户监视器看不到WF_CD状态，它可能会在ODETE-FTP收到更改方向（CD）命令之前发送F_EERP_RQ。
IDLE Connection IDLE
空闲连接空闲
IDLELI Idle Listener
IDLELI空闲侦听器
IDLELICD Idle Listener, F_CD_RQ Received
IDLELICD空闲侦听器，F_CD_RQ已接收
The ODETTE-FTP entity has become the Listener after receiving a Change Direction request (F_CD_RQ) from the User Monitor. The receipt of an End Session (ESID) is valid in this state.
ODETTE-FTP实体在收到来自用户监视器的更改方向请求（F_CD_RQ）后已成为侦听器。结束会话（ESID）的接收在此状态下有效。
IDLESP Idle Speaker
空闲扬声器
IDLESPCD Idle Speaker, F_CD_IND Sent
IDLESPCD空闲扬声器，F_CD_IND已发送
The ODETTE-FTP entity has sent a Change Direction indication (F_CD_IND) to the User Monitor. A Change Direction request (F_CD_RQ) is invalid in this state.
ODETTE-FTP实体已向用户监视器发送更改方向指示（F_CD_IND）。更改方向请求（F_CD_RQ）在此状态下无效。
I_WF_NC Initiator Waiting for Network Connection
I\u WF\u NC启动器正在等待网络连接
The Initiator has requested a new network connection and is waiting for a Connection confirmation (N_CON_CF) from the Network Service.
启动器已请求新的网络连接，正在等待网络服务的连接确认（N_CON_CF）。
I_WF_RM Initiator Waiting for Ready Message
I\u WF\u RM启动器正在等待就绪消息
Before sending Start Session (SSID), the Initiator must wait for a Ready Message (SSRM) from the Responder.
在发送启动会话（SSID）之前，发起方必须等待响应方发送就绪消息（SSRM）。
I_WF_SSID Initiator Waiting for SSID
I_WF_SSID启动器正在等待SSID
The Initiator has sent a Start Session (SSID) command and is waiting for Start Session from the Responder.
发起方已发送启动会话（SSID）命令，正在等待响应方的启动会话。
NRSTWFCD Negative End Response stored in WF_CD state
NRSTWFCD负端响应存储在WF_CD状态
Since the User Monitor doesn't see the WF_CD state, it may send F_NERP_RQ, before ODETTE-FTP receives a Change Direction (CD) command.
由于用户监视器看不到WF_CD状态，它可能会在ODETE-FTP收到更改方向（CD）命令之前发送F_NERP_RQ。
OPI Open Input (Data Transfer Phase)
OPI开放输入（数据传输阶段）
The Listener is waiting for the Speaker to send a Data Exchange Buffer.
侦听器正在等待说话者发送数据交换缓冲区。
OPIP Open Input Pending
OPIP打开输入挂起
The Listener has received a Start File (SFID) command and is waiting for the Start File response (F_START_FILE_RS) from its User Monitor.
侦听器已收到启动文件（SFID）命令，正在等待来自其用户监视器的启动文件响应（F_Start_File_RS）。
OPO Open Out (Data Transfer Phase)
OPO开放（数据传输阶段）
The Speaker has received a Start File Positive Answer (SFPA) and is waiting for a Data (F_DATA_RQ) or Close File (F_CLOSE_FILE) request from its User Monitor.
扬声器已收到开始文件肯定应答（SFPA），正在等待来自其用户监视器的数据（F_Data_RQ）或关闭文件（F_Close_File）请求。
OPOP Open Out Pending
OPOP开放待定
The Speaker has sent a Start File (SFID) command and is waiting for a Start File Answer (SFPA or SFNA).
扬声器已发送开始文件（SFID）命令，正在等待开始文件应答（SFPA或SFNA）。
OPOWFC Open Out Wait for Credit
OPOWFC开放等待信贷
The Speaker is waiting for a Set Credit (CDT) command before sending further Data Exchange buffers.
在发送进一步的数据交换缓冲区之前，扬声器正在等待设置信用（CDT）命令。
RTRP Ready to Receive (RTR) Pending
RTRP准备接收（RTR）挂起
The Listener has received an EERP or a NERP and is waiting for the Ready to Receive response (F_RTR_RS) from its User Monitor.
侦听器已收到EERP或NERP，正在等待来自其用户监视器的准备接收响应（F_RTR_RS）。
SFSTWFCD Start File Request stored in WF_CD state.
SFSTWFCD启动文件请求存储在WF_CD状态。
Since the User Monitor doesn't see the WF_CD state, it may send a Start File request (F_START_FILE_RQ) before the ODETTE-FTP receives a Change Direction (CD) command.
由于用户监视器看不到WF_CD状态，它可能会在ODETTE-FTP收到更改方向（CD）命令之前发送启动文件请求（F_Start_File_RQ）。
WF_CD Wait for Change Direction
WF_CD等待更改方向
The Listener wishes to become the Speaker and is waiting for a Change Direction (CD) command after sending an End File Positive Answer (EFPA) requesting change direction.
听者希望成为演讲者，并在发送请求更改方向的结束文件肯定应答（EFPA）后等待更改方向（CD）命令。
WF_RTR Wait for Ready To Receive
WF\U RTR等待准备接收
The Speaker has sent an End to End Response (EERP) or a Negative End Response (NERP) command and must wait for Ready To Receive (RTR) from the Listener.
说话人已发送端到端响应（EERP）或负端响应（NERP）命令，并且必须等待听话人的准备接收（RTR）。
WF_NDISC Wait for N_DISC_IND
WF\u NDISC等待N\u磁盘索引
ODETTE-FTP has sent an End Session (ESID) command and is waiting for a Disconnection indication (N_DISC_IND) from the Network Service.
ODETTE-FTP已发送结束会话（ESID）命令，正在等待网络服务的断开指示（N_DISC_IND）。
WF_SECD Wait for Security Change Direction
WF_SECD等待安全更改方向
The Speaker is expecting a Security Change Direction (SECD) from the Listener.
演讲者希望听众提供安全更改方向（SECD）。
WF_AUCH Wait for Authentication Challenge
WF_AUCH等待验证质询
The Speaker has sent a Security Change Direction (SECD) command and must wait for Authentication Challenge (AUCH) from the Listener.
说话人已发送安全更改方向（SECD）命令，必须等待侦听器发出身份验证质询（AUCH）。
WF_AURP Wait for Authentication Response
WF_AURP等待身份验证响应
The Speaker has sent an Authentication Challenge (AUCH) command and must wait for Authentication Response (AURP) from the Listener.
说话人已发送身份验证质询（AUCH）命令，必须等待侦听器的身份验证响应（AURP）。
User Monitor Input Events (Section 3)
用户监视器输入事件（第3节）
F_DATA_RQ F_CONNECT_RQ F_START_FILE_RQ F_CLOSE_FILE_RQ
F_EERP_RQ F_CONNECT_RS F_START_FILE_RS(+) F_CLOSE_FILE_RS(+)
F_NERP_RQ F_ABORT_RQ F_START_FILE_RS(-) F_CLOSE_FILE_RS(-)
F_CD_RQ F_RELEASE_RQ F_RTR_RS
F_DATA_RQ F_CONNECT_RQ F_START_FILE_RQ F_CLOSE_FILE_RQ
F_EERP_RQ F_CONNECT_RS F_START_FILE_RS(+) F_CLOSE_FILE_RS(+)
F_NERP_RQ F_ABORT_RQ F_START_FILE_RS(-) F_CLOSE_FILE_RS(-)
F_CD_RQ F_RELEASE_RQ F_RTR_RS
Network Input Events (Section 2.2)
网络输入事件（第2.2节）
N_CON_IND N_CON_CF N_DATA_IND N_DISC_IND N_RST_IND
N_CON_IND N_CON_CF N_DATA_IND N_DISC_IND N_RST IND
Peer ODETTE-FTP Input Events (Section 4)
对等ODETE-FTP输入事件（第4节）
SSID SFID SFPA SFNA EFID EFPA EFNA DATA ESID EERP RTR CD CDT SSRM NERP SECD AUCH AURP
SSID SFID SFPA SFNA EFID EFPA EFNA数据ESID EERP RTR CD CDT SSRM NERP SECD AUCH AURP
Internal Input Events
内部输入事件
TIME-OUT - Internal ODETTE-FTP timer expires.
超时-内部ODETTE-FTP计时器过期。
Input event parameters are denoted I.Event-name.Parameter-name within the state table action and predicate lists. Their value can be examined but not changed by the ODETTE-FTP entity.
输入事件参数在状态表动作和谓词列表中表示为I.event-name.Parameter-name。ODETTE-FTP实体可以检查它们的值，但不能更改它们的值。
User Monitor Output Events (Section 3)
用户监视器输出事件（第3节）
F_DATA_IND F_CONNECT_IND F_START_FILE_IND F_CLOSE_FILE_IND
F_EERP_IND F_CONNECT_CF F_START_FILE_CF(+) F_CLOSE_FILE_CF(+)
F_CD_IND F_ABORT_IND F_START_FILE_CF(-) F_CLOSE_FILE_CF(-)
F_NERP_IND F_RELEASE_IND F_DATA_CF F_RTR_CF
F_DATA_IND F_CONNECT_IND F_START_FILE_IND F_CLOSE_FILE_IND
F_EERP_IND F_CONNECT_CF F_START_FILE_CF(+) F_CLOSE_FILE_CF(+)
F_CD_IND F_ABORT_IND F_START_FILE_CF(-) F_CLOSE_FILE_CF(-)
F_NERP_IND F_RELEASE_IND F_DATA_CF F_RTR_CF
Network Output Events (Section 2.2)
网络输出事件（第2.2节）
N_CON_RQ N_CON_RS N_DATA_RQ N_DISC_RQ
N_CON_RQ N_CON_RS N_数据N_RQ N_光盘
Peer ODETTE-FTP Output Events (Section 4)
对等ODETE-FTP输出事件（第4节）
SSID SFID SFPA SFNA EFID EFPA EFNA DATA ESID EERP RTR CD CDT SSRM NERP SECD AUCH AURP
SSID SFID SFPA SFNA EFID EFPA EFNA数据ESID EERP RTR CD CDT SSRM NERP SECD AUCH AURP
Output event parameters are denoted O.Event-name.Parameter-name within the state table action and predicate lists. Their values can be examined and changed by the ODETTE-FTP entity.
输出事件参数在状态表动作和谓词列表中表示为O.event-name.Parameter-name。ODETTE-FTP实体可以检查和更改它们的值。
The following variables are maintained by the ODETTE-FTP entity to assist the operation of the protocol. They are denoted V.Variable-name within the state table action and predicate lists. Their value can be examined and changed by the ODETTE-FTP entity. The initial value of each variable is undefined.
以下变量由ODETTE-FTP实体维护，以协助协议的运行。它们在状态表动作和谓词列表中表示为V.Variable-name。ODETTE-FTP实体可以检查和更改它们的值。每个变量的初始值未定义。
Variable Type Comments
---------------------------------------------------------------------
Buf-size Integer Negotiated Data Exchange Buffer size.
Called-addr Address Used to build O.F_CONNECT_IND.Called-addr
Calling-addr Address To build O.F_CONNECT_IND.Calling-addr
Compression Yes/No Compression in use as agreed.
Credit_L Integer Listener's credit counter.
Credit_S Integer Speaker's credit counter.
Id String Used to build O.SSID.Id
Mode Sender-only, Receiver-only, Both.
Pswd String Password, used to build O.SSID.Pswd
Req-buf Primitive Input event (F_XXX_RQ) stored in WF_CD
state.
Restart Yes/No Restart in used as agreed.
Restart-pos Integer Used only during file opening.
Window Integer The credit value negotiated for the
session.
Caller Yes/No This entity initiated the ODETTE-FTP
session.
Authentication Yes/No Secure authentication in use as agreed
Challenge Binary Random challenge
---------------------------------------------------------------------
Variable Type Comments
---------------------------------------------------------------------
Buf-size Integer Negotiated Data Exchange Buffer size.
Called-addr Address Used to build O.F_CONNECT_IND.Called-addr
Calling-addr Address To build O.F_CONNECT_IND.Calling-addr
Compression Yes/No Compression in use as agreed.
Credit_L Integer Listener's credit counter.
Credit_S Integer Speaker's credit counter.
Id String Used to build O.SSID.Id
Mode Sender-only, Receiver-only, Both.
Pswd String Password, used to build O.SSID.Pswd
Req-buf Primitive Input event (F_XXX_RQ) stored in WF_CD
state.
Restart Yes/No Restart in used as agreed.
Restart-pos Integer Used only during file opening.
Window Integer The credit value negotiated for the
session.
Caller Yes/No This entity initiated the ODETTE-FTP
session.
Authentication Yes/No Secure authentication in use as agreed
Challenge Binary Random challenge
---------------------------------------------------------------------
The following constants define the capabilities of a given ODETTE-FTP entity. They are denoted C.Constant-name within the state table action and predicate lists. Their value can be examined but not changed by the ODETTE-FTP entity.
以下常量定义给定ODETTE-FTP实体的功能。它们在状态表动作和谓词列表中表示为C.Constant-name。ODETTE-FTP实体可以检查它们的值，但不能更改它们的值。
Constant Value Comments
---------------------------------------------------------------------
Cap-compression Yes/No Compression supported?
Cap-init Initiator Must be Initiator.
Responder Must be Responder.
Both Can be Initiator or Responder.
Cap-mode Sender-only Must be sender.
Receiver-only Must be receiver.
Both Can be sender or receiver.
Max-buf-size 127 < Int < 100000 Maximum Data Exchange Buffer
size supported.
Max-window 0 < Int < 1000 Local maximum credit value.
Cap-restart Yes/No Restart supported?
Cap-logic 0, 1, 2 0 = does not support special
logic
1 = supports special logic
2 = needs special logic
---------------------------------------------------------------------
Constant Value Comments
---------------------------------------------------------------------
Cap-compression Yes/No Compression supported?
Cap-init Initiator Must be Initiator.
Responder Must be Responder.
Both Can be Initiator or Responder.
Cap-mode Sender-only Must be sender.
Receiver-only Must be receiver.
Both Can be sender or receiver.
Max-buf-size 127 < Int < 100000 Maximum Data Exchange Buffer
size supported.
Max-window 0 < Int < 1000 Local maximum credit value.
Cap-restart Yes/No Restart supported?
Cap-logic 0, 1, 2 0 = does not support special
logic
1 = supports special logic
2 = needs special logic
---------------------------------------------------------------------
o----------------------------------------------------------o
| | Other States |
| |--------------------------------------------------o |
| | WF_SECD | |
| |----------------------------------------------o | |
| | WF_AURP | | |
| |------------------------------------------o | | |
| | WF_AUCH | | | |
| |--------------------------------------o | | | |
| S | A_WF_CONRS | | | | |
| |----------------------------------o | | | | |
| T | A_NC_ONLY | | | | | |
| |------------------------------o | | | | | |
| A | I_WF_SSID | | | | | | |
| |--------------------------o | | | | | | |
| T | I_WF_RM | | | | | | | |
| |----------------------o | | | | | | | |
| E | I_WF_NC | | | | | | | | |
| |------------------o | | | | | | | | |
| | IDLE | | | | | | | | | |
|==================o---+---+---+---+---+---+---+---+---+---|
| | F_CONNECT_RQ | A | X | X | X | X | X | X | X | X | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| E | N_CON_CF | X | C | X | X | X | X | X | X | X | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| V | SSRM | X | X | H | X | X | X | L | L | L | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| E | SSID | X | X | X | D | E | F | L | L | L | F |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| N | N_CON_IND | B | X | X | X | X | X | X | X | X | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| T | F_CONNECT_RS | X | U | U | U | U | G | X | X | X | U |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | ESID | X | X | X | F | X | X | F | F | F | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | AUCH | X | X | U | U | X | X | I | L | L | U |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | AURP | X | X | U | U | X | X | L | K | L | U |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | SECD | X | X | U | U | X | X | L | L | J | U |
o----------------------------------------------------------o
o----------------------------------------------------------o
| | Other States |
| |--------------------------------------------------o |
| | WF_SECD | |
| |----------------------------------------------o | |
| | WF_AURP | | |
| |------------------------------------------o | | |
| | WF_AUCH | | | |
| |--------------------------------------o | | | |
| S | A_WF_CONRS | | | | |
| |----------------------------------o | | | | |
| T | A_NC_ONLY | | | | | |
| |------------------------------o | | | | | |
| A | I_WF_SSID | | | | | | |
| |--------------------------o | | | | | | |
| T | I_WF_RM | | | | | | | |
| |----------------------o | | | | | | | |
| E | I_WF_NC | | | | | | | | |
| |------------------o | | | | | | | | |
| | IDLE | | | | | | | | | |
|==================o---+---+---+---+---+---+---+---+---+---|
| | F_CONNECT_RQ | A | X | X | X | X | X | X | X | X | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| E | N_CON_CF | X | C | X | X | X | X | X | X | X | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| V | SSRM | X | X | H | X | X | X | L | L | L | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| E | SSID | X | X | X | D | E | F | L | L | L | F |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| N | N_CON_IND | B | X | X | X | X | X | X | X | X | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| T | F_CONNECT_RS | X | U | U | U | U | G | X | X | X | U |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | ESID | X | X | X | F | X | X | F | F | F | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | AUCH | X | X | U | U | X | X | I | L | L | U |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | AURP | X | X | U | U | X | X | L | K | L | U |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | SECD | X | X | U | U | X | X | L | L | J | U |
o----------------------------------------------------------o
I | Predicate Actions Output Events Next State
===o=============================================================
A | P1: F_ABORT_IND IDLE
| !P1: 1,2 N_CON_RQ I_WF_NC
---+-------------------------------------------------------------
B | P3: N_DISC_RQ IDLE
| !P3: 2 N_CON_RS
| SSRM A_NC_ONLY
---+-------------------------------------------------------------
C | 4,2 I_WF_RM
---+-------------------------------------------------------------
D | P2 & P8 & P11: 4,2,5 SECD WF_AUCH
| P2 & P8 & !P11: 4,2,5 F_CONNECT_CF IDLESP
| P2 & !P8: 4,2 ESID(R=12)
| F_ABORT_IND(R,AO=L) WF_NDISC
| else: 4,2 ESID(R=10)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
E | P4: 4 N_DISC_RQ IDLE
| !P4: 4,2 F_CONNECT_IND A_WF_CONRS
---+-------------------------------------------------------------
F | 4 F_ABORT_IND
| N_DISC_RQ IDLE
---+-------------------------------------------------------------
G | P2 & P9 & P10: 4,2,5 SSID WF_SECD
| P2 & !P9 & P10: 4,2,5 SSID IDLELI
| !P10: 4,2 ESID(R=12)
| F_ABORT_IND(R,AO=L) WF_NDISC
| else: 4,2 ESID(R=10)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
H | 4,2,3 SSID I_WF_SSID
---+-------------------------------------------------------------
I | P5: 4,2 AURP WF_SECD
| !P5: 4,2 AURP IDLELI
---+-------------------------------------------------------------
J | 4,2 AUCH WF_AURP
---+-------------------------------------------------------------
K | P6: 4,2 F_CONNECT_CF IDLESP
| P7: 4,2 SECD WF_AUCH
| else: 4,2 ESID(R=11)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
L | 4,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
I | Predicate Actions Output Events Next State
===o=============================================================
A | P1: F_ABORT_IND IDLE
| !P1: 1,2 N_CON_RQ I_WF_NC
---+-------------------------------------------------------------
B | P3: N_DISC_RQ IDLE
| !P3: 2 N_CON_RS
| SSRM A_NC_ONLY
---+-------------------------------------------------------------
C | 4,2 I_WF_RM
---+-------------------------------------------------------------
D | P2 & P8 & P11: 4,2,5 SECD WF_AUCH
| P2 & P8 & !P11: 4,2,5 F_CONNECT_CF IDLESP
| P2 & !P8: 4,2 ESID(R=12)
| F_ABORT_IND(R,AO=L) WF_NDISC
| else: 4,2 ESID(R=10)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
E | P4: 4 N_DISC_RQ IDLE
| !P4: 4,2 F_CONNECT_IND A_WF_CONRS
---+-------------------------------------------------------------
F | 4 F_ABORT_IND
| N_DISC_RQ IDLE
---+-------------------------------------------------------------
G | P2 & P9 & P10: 4,2,5 SSID WF_SECD
| P2 & !P9 & P10: 4,2,5 SSID IDLELI
| !P10: 4,2 ESID(R=12)
| F_ABORT_IND(R,AO=L) WF_NDISC
| else: 4,2 ESID(R=10)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
H | 4,2,3 SSID I_WF_SSID
---+-------------------------------------------------------------
I | P5: 4,2 AURP WF_SECD
| !P5: 4,2 AURP IDLELI
---+-------------------------------------------------------------
J | 4,2 AUCH WF_AURP
---+-------------------------------------------------------------
K | P6: 4,2 F_CONNECT_CF IDLESP
| P7: 4,2 SECD WF_AUCH
| else: 4,2 ESID(R=11)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
L | 4,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
Predicate P1: (No resources available) OR (C.Cap-init = Responder) OR (C.Cap-mode = Sender-only AND I.F_CONNECT_RQ.Mode = Receiver-only) OR (C.Cap-mode = Receiver-only AND I.F_CONNECT_RQ.Mode = Sender-only)
谓词P1：（无可用资源）或（C.Cap-init=Responder）或（C.Cap-mode=Sender only和I.F\u CONNECT\u RQ.mode=Receiver only）或（C.Cap-mode=Receiver only和I.F\u CONNECT\u RQ.mode=Sender only）
Predicate P2: SSID negotiation is successful (for these, Buf-size, Restart, Compression, Mode, Special logic, and Window, compare the inbound SSID with the local constants to set the local variables. Any incompatibilities result in failure of the negotiation.)
谓词P2:SSID协商成功（对于这些，Buf大小、重新启动、压缩、模式、特殊逻辑和窗口，将入站SSID与本地常量进行比较以设置本地变量。任何不兼容都会导致协商失败。）
Predicate P3: C.Cap-init = Initiator
谓词P3:C.Cap-init=启动器
Predicate P4: Mode in SSID incompatible with C.Cap-mode
谓词P4:SSID中的模式与C.Cap-Mode不兼容
Predicate P5: V.Caller = Yes
谓词P5:V.Caller=Yes
Predicate P6: (V.Caller = Yes) AND (AURP.Signature verifies with V.Challenge)
谓词P6：（V.Caller=Yes）和（AURP.Signature用V.Challenge验证）
Predicate P7: (V.Caller = No) AND (AURP.Signature verifies with V.Challenge)
谓词P7：（V.Caller=No）和（AURP.Signature用V.Challenge验证）
Predicate P8: V.Authentication = I.SSID.Authentication
谓词P8:V.Authentication=I.SSID.Authentication
Predicate P9: I.F_CONNECT_RS.Authentication = Yes
谓词P9:I.F_CONNECT_RS.Authentication=Yes
Predicate P10: O.F_CONNECT_IND.Authentication = I.F_CONNECT_RS.Authentication
谓词P10:O.F\u CONNECT\u IND.Authentication=I.F\u CONNECT\u RS.Authentication
Predicate P11: V.Authentication = Yes
谓词P11:V.身份验证=是
Action 1: Set V.Mode from (C.Cap-mode, I.F_CONNECT_RQ.Mode) Set V.Pswd, V.Id, V.Restart, and V.Authentication from I.F_CONNECT_RQ Set V.Buf-size = C.Max-buf-size Set V.Compression = C.Cap-compression Set V.Caller = Yes Build O.N_CON_RQ
操作1：从（C.Cap-Mode，I.F\u CONNECT\u RQ.Mode）设置V.Pswd，V.Id，V.Restart和V.Authentication from I.F\u CONNECT\u RQ Set V.Buf-size=C.Max-Buf-size Set V.Compression=C.Cap-Compression Set V.Caller=Yes Build O.N\u CON\u RQ
Action 2: Start inactivity timer
操作2：启动非活动计时器
Action 3: Set parameters in O.SSID = from local variables
操作3：设置O.SSID=中的参数来自局部变量
Action 4: Stop timer
动作4：停止计时器
Action 5: Set V.Mode, V.Restart, V.Compression, V.Buf-size, V.Window, V.Authentication = from SSID
操作5：设置V.模式、V.重新启动、V.压缩、V.Buf-size、V.窗口、V.身份验证=来自SSID
Action 6: Set V.Challenge = A random number unique to the session
动作6：设置V.挑战=会话唯一的随机数
o--------------------------------------o
| | Other States |
| S |------------------------------o |
| T | WF_NDISC | |
| A |--------------------------o | |
| T | I_WF_NC | | |
| E |----------------------o | | |
| | IDLE | | | |
|======================o---+---+---+---|
| | TIME-OUT | X | X | A | B |
| |------------------+---+---+---+---|
| E | F_ABORT_RQ | X | A | X | C |
| V |------------------+---+---+---+---|
| E | N_RST_IND | X | X | A | D |
| N |------------------+---+---+---+---|
| T | N_DISC_IND | X | E | F | G |
| |------------------+---+---+---+---|
| | Invalid Buffer | X | X | H | I |
o--------------------------------------o
o--------------------------------------o
| | Other States |
| S |------------------------------o |
| T | WF_NDISC | |
| A |--------------------------o | |
| T | I_WF_NC | | |
| E |----------------------o | | |
| | IDLE | | | |
|======================o---+---+---+---|
| | TIME-OUT | X | X | A | B |
| |------------------+---+---+---+---|
| E | F_ABORT_RQ | X | A | X | C |
| V |------------------+---+---+---+---|
| E | N_RST_IND | X | X | A | D |
| N |------------------+---+---+---+---|
| T | N_DISC_IND | X | E | F | G |
| |------------------+---+---+---+---|
| | Invalid Buffer | X | X | H | I |
o--------------------------------------o
I | Predicate Actions Output Events Next State
===o=================================================================
A | N_DISC_RQ IDLE
---+-----------------------------------------------------------------
B | F_ABORT_IND
| N_DISC_RQ IDLE
---+-----------------------------------------------------------------
C | 1 N_DISC_RQ IDLE
---+-----------------------------------------------------------------
D | 1 N_DISC_RQ
| F_ABORT_IND IDLE
---+-----------------------------------------------------------------
E | F_ABORT_IND IDLE
---+-----------------------------------------------------------------
F | 1 IDLE
---+-----------------------------------------------------------------
G | 1 F_ABORT_IND IDLE
---+-----------------------------------------------------------------
H | WF_NDISC
---+-----------------------------------------------------------------
I | 1,2 ESID(R=01)
| F_ABORT_IND(R,AO=L) WF_NDISC
---------------------------------------------------------------------
I | Predicate Actions Output Events Next State
===o=================================================================
A | N_DISC_RQ IDLE
---+-----------------------------------------------------------------
B | F_ABORT_IND
| N_DISC_RQ IDLE
---+-----------------------------------------------------------------
C | 1 N_DISC_RQ IDLE
---+-----------------------------------------------------------------
D | 1 N_DISC_RQ
| F_ABORT_IND IDLE
---+-----------------------------------------------------------------
E | F_ABORT_IND IDLE
---+-----------------------------------------------------------------
F | 1 IDLE
---+-----------------------------------------------------------------
G | 1 F_ABORT_IND IDLE
---+-----------------------------------------------------------------
H | WF_NDISC
---+-----------------------------------------------------------------
I | 1,2 ESID(R=01)
| F_ABORT_IND(R,AO=L) WF_NDISC
---------------------------------------------------------------------
Action 1: Stop inactivity timer
操作1：停止非活动计时器
Action 2: Start inactivity timer
操作2：启动非活动计时器
The following abbreviations are used in the Speaker state table.
以下缩略语用于扬声器状态表。
F_REL_RQ(Ok) - F_RELEASE_RQ Reason = Normal
F_REL_RQ(Err) - F_RELEASE_RQ Reason = Error
F_REL_RQ(Ok) - F_RELEASE_RQ Reason = Normal
F_REL_RQ(Err) - F_RELEASE_RQ Reason = Error
o--------------------------------------------------------------------o
| | Other States |
| |--------------------------------------------------------------o |
| | WF_NDISC | |
| |----------------------------------------------------------o | |
| | OPOWFC | | |
o--------------------------------------------------------------------o
| | Other States |
| |--------------------------------------------------------------o |
| | WF_NDISC | |
| |----------------------------------------------------------o | |
| | OPOWFC | | |
| |------------------------------------------------------o | | |
| | OPO | | | |
|S|--------------------------------------------------o | | | |
| | OPOP | | | | |
|T|----------------------------------------------o | | | | |
| | CDSTWFCD | | | | | |
|A|------------------------------------------o | | | | | |
| | SFSTWFCD | | | | | | |
|T|--------------------------------------o | | | | | | |
| | NRSTWFCD | | | | | | | |
|E|----------------------------------o | | | | | | | |
| | ERSTWFCD | | | | | | | | |
| |------------------------------o | | | | | | | | |
| | WF_CD | | | | | | | | | |
| |--------------------------o | | | | | | | | | |
| | WF_RTR | | | | | | | | | | |
| |----------------------o | | | | | | | | | | |
| | IDLESPCD | | | | | | | | | | | |
| |------------------o | | | | | | | | | | | |
| | IDLESP | | | | | | | | | | | | |
|=+==============o---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_EERP_RQ | A | A | W | F | W | W | U | U | U | U | U | U | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_NERP_RQ | Y | Y | W | Z | W | W | U | U | U | U | U | U | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_START_ | B | B | W | G | W | W | U | U | U | U | U | X | U |
| | FILE_RQ | | | | | | | | | | | | | |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | SFPA | C | C | C | C | C | C | C | C | K | C | C | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|E| SFNA | C | C | C | C | C | C | C | C | L | C | C | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|V| CD | C | C | C | H | R | Z1| I | J | C | C | C | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|E| F_DATA_RQ | U | U | U | U | U | U | U | U | U | M | U | S | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|N| CDT | C | C | C | C | C | C | C | C | C | P | O | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|T| F_CD_RQ | D | U | W | T | W | W | U | U | U | U | U | X | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_REL_RQ(Ok) | U | E | U | U | U | U | U | U | U | U | U | X | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_REL_RQ(Err)| Q | Q | Q | Q | Q | Q | Q | Q | Q | Q | Q | S | Q |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | RTR | C | C | N | C | C | C | C | C | C | C | C | S | C |
o--------------------------------------------------------------------o
| |------------------------------------------------------o | | |
| | OPO | | | |
|S|--------------------------------------------------o | | | |
| | OPOP | | | | |
|T|----------------------------------------------o | | | | |
| | CDSTWFCD | | | | | |
|A|------------------------------------------o | | | | | |
| | SFSTWFCD | | | | | | |
|T|--------------------------------------o | | | | | | |
| | NRSTWFCD | | | | | | | |
|E|----------------------------------o | | | | | | | |
| | ERSTWFCD | | | | | | | | |
| |------------------------------o | | | | | | | | |
| | WF_CD | | | | | | | | | |
| |--------------------------o | | | | | | | | | |
| | WF_RTR | | | | | | | | | | |
| |----------------------o | | | | | | | | | | |
| | IDLESPCD | | | | | | | | | | | |
| |------------------o | | | | | | | | | | | |
| | IDLESP | | | | | | | | | | | | |
|=+==============o---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_EERP_RQ | A | A | W | F | W | W | U | U | U | U | U | U | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_NERP_RQ | Y | Y | W | Z | W | W | U | U | U | U | U | U | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_START_ | B | B | W | G | W | W | U | U | U | U | U | X | U |
| | FILE_RQ | | | | | | | | | | | | | |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | SFPA | C | C | C | C | C | C | C | C | K | C | C | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|E| SFNA | C | C | C | C | C | C | C | C | L | C | C | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|V| CD | C | C | C | H | R | Z1| I | J | C | C | C | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|E| F_DATA_RQ | U | U | U | U | U | U | U | U | U | M | U | S | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|N| CDT | C | C | C | C | C | C | C | C | C | P | O | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|T| F_CD_RQ | D | U | W | T | W | W | U | U | U | U | U | X | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_REL_RQ(Ok) | U | E | U | U | U | U | U | U | U | U | U | X | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_REL_RQ(Err)| Q | Q | Q | Q | Q | Q | Q | Q | Q | Q | Q | S | Q |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | RTR | C | C | N | C | C | C | C | C | C | C | C | S | C |
o--------------------------------------------------------------------o
I | Predicate Actions Output Events Next State
===o=================================================================
A | P5: 1,2,3,18 EERP WF_RTR
| !P5: 1,2,3 EERP WF_RTR
---+-----------------------------------------------------------------
B | P1: UE
| !P1: 1,2,5 SFID OPOP
---+-----------------------------------------------------------------
C | 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
D | 1,2 CD IDLELICD
---+-----------------------------------------------------------------
E | 1,2 ESID(R=00) WF_NDISC
---+-----------------------------------------------------------------
F | 4 ERSTWFCD
---+-----------------------------------------------------------------
G | P1: UE
| !P1: 6 SFSTWFCD
---+-----------------------------------------------------------------
H | 1,2 IDLESP
---+-----------------------------------------------------------------
I | 1,2,10 SFID OPOP
---+-----------------------------------------------------------------
J | 1,2 CD IDLELICD
---+-----------------------------------------------------------------
K | P2: 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
| !P2: 1,2,7,12 F_START_FILE_CF(+) OPO
---+-----------------------------------------------------------------
L | 1,2,8 F_START_FILE_CF(-) IDLESP
---+-----------------------------------------------------------------
M | P3: 1,2,11,13 DATA OPOWFC
| !P3: 1,2,11,13 DATA
| F_DATA_CF OPO
---+-----------------------------------------------------------------
N | F_RTR_CF IDLESP
---+-----------------------------------------------------------------
O | 12 F_DATA_CF OPO
---+-----------------------------------------------------------------
P | Protocol 1,2 ESID(R=02)
| Error F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
Q | 1,2 ESID(R) WF_NDISC
---+-----------------------------------------------------------------
Continued -->
I | Predicate Actions Output Events Next State
===o=================================================================
A | P5: 1,2,3,18 EERP WF_RTR
| !P5: 1,2,3 EERP WF_RTR
---+-----------------------------------------------------------------
B | P1: UE
| !P1: 1,2,5 SFID OPOP
---+-----------------------------------------------------------------
C | 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
D | 1,2 CD IDLELICD
---+-----------------------------------------------------------------
E | 1,2 ESID(R=00) WF_NDISC
---+-----------------------------------------------------------------
F | 4 ERSTWFCD
---+-----------------------------------------------------------------
G | P1: UE
| !P1: 6 SFSTWFCD
---+-----------------------------------------------------------------
H | 1,2 IDLESP
---+-----------------------------------------------------------------
I | 1,2,10 SFID OPOP
---+-----------------------------------------------------------------
J | 1,2 CD IDLELICD
---+-----------------------------------------------------------------
K | P2: 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
| !P2: 1,2,7,12 F_START_FILE_CF(+) OPO
---+-----------------------------------------------------------------
L | 1,2,8 F_START_FILE_CF(-) IDLESP
---+-----------------------------------------------------------------
M | P3: 1,2,11,13 DATA OPOWFC
| !P3: 1,2,11,13 DATA
| F_DATA_CF OPO
---+-----------------------------------------------------------------
N | F_RTR_CF IDLESP
---+-----------------------------------------------------------------
O | 12 F_DATA_CF OPO
---+-----------------------------------------------------------------
P | Protocol 1,2 ESID(R=02)
| Error F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
Q | 1,2 ESID(R) WF_NDISC
---+-----------------------------------------------------------------
Continued -->
I | Predicate Actions Output Events Next State
===o=================================================================
R | 1,2,9 EERP WF_RTR
---+-----------------------------------------------------------------
S | WF_NDISC
---+-----------------------------------------------------------------
T | CDSTWFCD
---+-----------------------------------------------------------------
U | User Error UE
---+-----------------------------------------------------------------
W | User Error - Note 1 UE
---+-----------------------------------------------------------------
X | Error
---+-----------------------------------------------------------------
Y | P4 & P5: 1,2,15,18 NERP WF_RTR
| !P4 & !P5: 1,2,15,14 NERP WF_RTR
| P4 & !P5: 1,2,15 NERP WF_RTR
| !P4 & P5: 1,2,15,14,18 NERP WF_RTR
---+-----------------------------------------------------------------
Z | 16 NRSTWFCD
---------------------------------------------------------------------
Z1| P4: 1,2,17 NERP WF_RTR
| !P4: 1,2,17,14 NERP WF_RTR
---------------------------------------------------------------------
I | Predicate Actions Output Events Next State
===o=================================================================
R | 1,2,9 EERP WF_RTR
---+-----------------------------------------------------------------
S | WF_NDISC
---+-----------------------------------------------------------------
T | CDSTWFCD
---+-----------------------------------------------------------------
U | User Error UE
---+-----------------------------------------------------------------
W | User Error - Note 1 UE
---+-----------------------------------------------------------------
X | Error
---+-----------------------------------------------------------------
Y | P4 & P5: 1,2,15,18 NERP WF_RTR
| !P4 & !P5: 1,2,15,14 NERP WF_RTR
| P4 & !P5: 1,2,15 NERP WF_RTR
| !P4 & P5: 1,2,15,14,18 NERP WF_RTR
---+-----------------------------------------------------------------
Z | 16 NRSTWFCD
---------------------------------------------------------------------
Z1| P4: 1,2,17 NERP WF_RTR
| !P4: 1,2,17,14 NERP WF_RTR
---------------------------------------------------------------------
Predicate P1: (I.F_START_FILE_RQ.Restart-pos > 0 AND V.Restart = No)
OR (V.Mode = Receiver-only)
Predicate P1: (I.F_START_FILE_RQ.Restart-pos > 0 AND V.Restart = No)
OR (V.Mode = Receiver-only)
Note: Restart requested and not supported for this session.
注意：此会话已请求重新启动，但不支持重新启动。
Predicate P2: I.SFPA.Restart-pos > V.Restart-pos
谓词P2:I.SFPA.Restart-pos>V.Restart-pos
Note: Protocol error due to the restart position in the SFPA acknowledgement being greater than the position requested in the SFID request.
注意：由于SFPA确认中的重新启动位置大于SFID请求中请求的位置，导致协议错误。
Predicate P3: V.Credit_S - 1 = 0
Predicate P3: V.Credit_S - 1 = 0
Note: Speaker's Credit is exhausted.
注：演讲者的信用已用完。
Predicate P4: No special logic is in use
谓词P4：未使用特殊逻辑
Predicate P5: Signed EERP/NERP requested
谓词P5：请求的已签名EERP/NERP
Action 1: Stop inactivity timer
操作1：停止非活动计时器
Action 2: Start inactivity timer
操作2：启动非活动计时器
Action 3: Build an EERP from F_EERP_RQ
行动3：从F_EERP_RQ构建EERP
Action 4: Store F_EERP_RQ in V.Req-buf
措施4：将F_EERP_RQ存储在V.Req-buf中
Action 5: Build SFID from F_START_FILE_RQ V.Restart-pos = I.F_START_FILE_RQ.Restart-pos
操作5：从F_START_文件\u RQ V.Restart-pos=I.F_START_文件\u RQ.Restart-pos生成SFID
Action 6: Store F_START_FILE_RQ in V.Req-buf
操作6：在V.Req-buf中存储F_START_文件
Action 7: Build F_START_FILE_CF(+) from I.SFPA
Action 7: Build F_START_FILE_CF(+) from I.SFPA
Action 8: Build F_START_FILE_CF(-) from I.SFNA
操作8：从I.SFNA生成F_START_文件\u CF（-）
Action 9: Build EERP from F_EERP_RQ stored in V.Req-buf
操作9：从V.Req-buf中存储的F_EERP_RQ构建EERP
Action 10: Build SFID from F_START_FILE_RQ stored in V.Req-buf Set V.Restart-pos
操作10：从存储在V.Req-buf Set V.Restart-pos中的F_START_文件构建SFID
Action 11: Build Exchange Buffer
操作11：生成Exchange缓冲区
Action 12: V.Credit_S = V.Window
行动12:V.Credit\u S=V.Window
Action 13: V.Credit_S = V.Credit_S - 1
Action 13: V.Credit_S = V.Credit_S - 1
Action 14: Activate CRC-calculus function. Wrap Exchange buffer in special logic
动作14：激活CRC演算功能。用特殊逻辑包装交换缓冲区
Action 15: Build a NERP from F_NERP_RQ
Action 15: Build a NERP from F_NERP_RQtranslate error, please retry
Action 16: Store F_NERP_RQ in V.Req-buf
措施16：在V.Req-buf中存储F_NERP_RQ
Action 17: Build NERP from F_NERP_RQ stored in V.Req-buf
措施17：从存储在V.Req-buf中的F_NERP_RQ构建NERP
Action 18: Sign the contents of NERP/EERP
行动18：签署NERP/EERP的内容
Note 1: Whether to accept this "Request/Event" while in this state is a matter of local implementation. The ODETTE state tables are based on the assumption that this event cannot occur in this state and is considered to be a user error (UE).
注1：在此状态下是否接受此“请求/事件”取决于本地实现。ODETTE状态表基于这样的假设，即此事件在此状态下不会发生，并被视为用户错误（UE）。
o---------------------------------o
| S | CLOP |
| T |-------------------------o |
| A | OPOWFC | |
| T |---------------------o | |
| E | OPO | | |
|=====================o---+---+---|
| E | F_CLOSE_FILE_RQ | A | E | U |
| V |-----------------+---+---+---|
| E | EFPA | B | B | C |
| N |-----------------+---+---+---|
| T | EFNA | B | B | D |
o---------------------------------o
o---------------------------------o
| S | CLOP |
| T |-------------------------o |
| A | OPOWFC | |
| T |---------------------o | |
| E | OPO | | |
|=====================o---+---+---|
| E | F_CLOSE_FILE_RQ | A | E | U |
| V |-----------------+---+---+---|
| E | EFPA | B | B | C |
| N |-----------------+---+---+---|
| T | EFNA | B | B | D |
o---------------------------------o
I | Predicate Actions Output Events Next State
===o=================================================================
A | 1,2,5,7 EFID CLOP
---+-----------------------------------------------------------------
B | 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
C | P1: 1,2,3 F_CLOSE_FILE_CF(+,SP=No)
| CD IDLELI
| !P1: 1,2,4 F_CLOSE_FILE_CF(+,SP=Yes) IDLESP
---+-----------------------------------------------------------------
D | 1,2,6 F_CLOSE_FILE_CF(-) IDLESP
---+-----------------------------------------------------------------
E | See Note 1
---+-----------------------------------------------------------------
U | User Error UE
---------------------------------------------------------------------
I | Predicate Actions Output Events Next State
===o=================================================================
A | 1,2,5,7 EFID CLOP
---+-----------------------------------------------------------------
B | 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
C | P1: 1,2,3 F_CLOSE_FILE_CF(+,SP=No)
| CD IDLELI
| !P1: 1,2,4 F_CLOSE_FILE_CF(+,SP=Yes) IDLESP
---+-----------------------------------------------------------------
D | 1,2,6 F_CLOSE_FILE_CF(-) IDLESP
---+-----------------------------------------------------------------
E | See Note 1
---+-----------------------------------------------------------------
U | User Error UE
---------------------------------------------------------------------
Predicate P1: (I.EFPA.CD-Request = Yes)
谓词P1：（I.EFPA.CD-Request=Yes）
Predicate P2: No special logic is in use
谓词P2：未使用特殊逻辑
Action 1: Stop inactivity timer
操作1：停止非活动计时器
Action 2: Start inactivity timer
操作2：启动非活动计时器
Action 3: O.F_CLOSE_FILE_CF(+).Speaker = No
Action 3: O.F_CLOSE_FILE_CF(+).Speaker = No
Action 4: O.F_CLOSE_FILE_CF(+).Speaker = Yes
Action 4: O.F_CLOSE_FILE_CF(+).Speaker = Yes
Action 5: Build EFID from F_CLOSE_FILE_RQ
操作5：从F_CLOSE_文件\u RQ生成EFID
Action 6: Build F_CLOSE_FILE_CF(-) from EFNA
操作6：从EFNA生成F_CLOSE_文件\u CF（-）
Action 7: Set V.Credit_S = 0
动作7：设置V.Credit\u S=0
Action 8: Wrap Exchange buffer in special logic
操作8：在特殊逻辑中包装Exchange缓冲区
Note 1: In order to respect the "half duplex" property of ODETTE-FTP, it is forbidden to send EFID while in the OPOWFC state. EFID can be sent only in the OPO state.
注1：为了尊重ODETTE-FTP的“半双工”特性，禁止在OPOWFC状态下发送EFID。EFID只能在OPO状态下发送。
The ODETTE-FTP implementation must avoid sending EFID (or receiving F_CLOSE_FILE_RQ) while in the OPOWFC state.
ODETTE-FTP实现必须避免在OPOWFC状态下发送EFID（或接收F_CLOSE_FILE_RQ）。
o---------------------------------------------o
| | RTRP |
| |-------------------------------------o |
| | CLIP | |
| |---------------------------------o | |
| | OPI | | |
| S |-----------------------------o | | |
| T | OPIP | | | |
| A |-------------------------o | | | |
| T | IDLELICD | | | | |
| E |---------------------o | | | | |
| | IDLELI | | | | | |
|=====================o---+---+---+---+---+---+
| | SFID | A | A | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| E | DATA | B | B | B | I | B | B |
| V |-----------------+---+---+---+---+---+---+
| E | EFID | B | B | B | J | B | B |
| N |-----------------+---+---+---+---+---+---+
| T | F_START_FILE_RS | U | U | H | U | U | U |
| |-----------------+---+---+---+---+---+---+
| | F_CLOSE_FILE_RS | U | U | U | U | K | U |
| |-----------------+---+---+---+---+---+---+
| | CD | C | B | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| | ESID R=Normal | D | F | D | D | D | D |
| |-----------------+---+---+---+---+---+---+
| | ESID R=Error | D | D | D | D | D | D |
| |-----------------+---+---+---+---+---+---+
| | EERP | E | E | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| | NERP | L | L | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| | F_RTR_RS | U | U | U | U | U | M |
o---------------------------------------------o
o---------------------------------------------o
| | RTRP |
| |-------------------------------------o |
| | CLIP | |
| |---------------------------------o | |
| | OPI | | |
| S |-----------------------------o | | |
| T | OPIP | | | |
| A |-------------------------o | | | |
| T | IDLELICD | | | | |
| E |---------------------o | | | | |
| | IDLELI | | | | | |
|=====================o---+---+---+---+---+---+
| | SFID | A | A | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| E | DATA | B | B | B | I | B | B |
| V |-----------------+---+---+---+---+---+---+
| E | EFID | B | B | B | J | B | B |
| N |-----------------+---+---+---+---+---+---+
| T | F_START_FILE_RS | U | U | H | U | U | U |
| |-----------------+---+---+---+---+---+---+
| | F_CLOSE_FILE_RS | U | U | U | U | K | U |
| |-----------------+---+---+---+---+---+---+
| | CD | C | B | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| | ESID R=Normal | D | F | D | D | D | D |
| |-----------------+---+---+---+---+---+---+
| | ESID R=Error | D | D | D | D | D | D |
| |-----------------+---+---+---+---+---+---+
| | EERP | E | E | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| | NERP | L | L | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| | F_RTR_RS | U | U | U | U | U | M |
o---------------------------------------------o
I | Predicate Actions Output Events Next State
===o=================================================================
A | P1: 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
| !P1: 1,2,3 F_START_FILE_IND OPIP
---+-----------------------------------------------------------------
B | 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
C | 1,2 F_CD_IND IDLESPCD
---+-----------------------------------------------------------------
D | 1 F_ABORT_IND(Received
| ESID Reason,AO=D)
| N_DISC_RQ IDLE
---+-----------------------------------------------------------------
E | 1,2,4 F_EERP_IND RTRP
---+-----------------------------------------------------------------
F | 1 F_RELEASE_IND
| N_DISC_RQ IDLE
---+-----------------------------------------------------------------
H | P4: User Error UE
| P2 & !P4 & !P5: 1,2,8 SFPA OPI
| !P2 & !P4 & !P5: 1,2 SFNA IDLELI
| P2 & !P4 & P5: 1,2,5,8 SFPA OPI
| !P2 & !P4 & P5: 1,2,5 SFNA IDLELI
---+-----------------------------------------------------------------
I | P6: 1,2 ESID(R=02)
| F_ABORT_IND(R,A0=L) WF_NDISC
| !P5 & !P6 & !P7: 1,2,7 F_DATA_IND (See Note 1) OPI
| !P5 & !P6 & P7: 1,2,8 F_DATA_IND
| CDT (See Note 1) OPI
| P5 & !P6 & P8: 1,2 ESID(R=07)
| F_ABORT_IND(R,A0=L) WF_NDISC
| P5 & !P6 & !P7 : 1,2,6,7 F_DATA_IND (See Note 1) OPI
| & !P8
| P5 & !P6 & P7 : 1,2,5,6,8 F_DATA_IND OPI
| & !P8 CDT (See Note 1)
---+-----------------------------------------------------------------
J | 1,2 F_CLOSE_FILE_IND CLIP
---+-----------------------------------------------------------------
K | P2 & P3 & !P5: 1,2 EFPA(CD-Req) WF_CD
| P2 & !P3 & !P5: 1,2 EFPA(no CD) IDLELI
| !P2 & !P5: 1,2 EFNA IDLELI
| P2 & !P3 & P5: 1,2,5 EFPA(no CD) IDLELI
| !P2 & P5: 1,2,5 EFNA IDLELI
| P2 & P3 & P5: 1,2,5 EFPA(CD-Req) WF_CD
I | Predicate Actions Output Events Next State
===o=================================================================
A | P1: 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
| !P1: 1,2,3 F_START_FILE_IND OPIP
---+-----------------------------------------------------------------
B | 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
C | 1,2 F_CD_IND IDLESPCD
---+-----------------------------------------------------------------
D | 1 F_ABORT_IND(Received
| ESID Reason,AO=D)
| N_DISC_RQ IDLE
---+-----------------------------------------------------------------
E | 1,2,4 F_EERP_IND RTRP
---+-----------------------------------------------------------------
F | 1 F_RELEASE_IND
| N_DISC_RQ IDLE
---+-----------------------------------------------------------------
H | P4: User Error UE
| P2 & !P4 & !P5: 1,2,8 SFPA OPI
| !P2 & !P4 & !P5: 1,2 SFNA IDLELI
| P2 & !P4 & P5: 1,2,5,8 SFPA OPI
| !P2 & !P4 & P5: 1,2,5 SFNA IDLELI
---+-----------------------------------------------------------------
I | P6: 1,2 ESID(R=02)
| F_ABORT_IND(R,A0=L) WF_NDISC
| !P5 & !P6 & !P7: 1,2,7 F_DATA_IND (See Note 1) OPI
| !P5 & !P6 & P7: 1,2,8 F_DATA_IND
| CDT (See Note 1) OPI
| P5 & !P6 & P8: 1,2 ESID(R=07)
| F_ABORT_IND(R,A0=L) WF_NDISC
| P5 & !P6 & !P7 : 1,2,6,7 F_DATA_IND (See Note 1) OPI
| & !P8
| P5 & !P6 & P7 : 1,2,5,6,8 F_DATA_IND OPI
| & !P8 CDT (See Note 1)
---+-----------------------------------------------------------------
J | 1,2 F_CLOSE_FILE_IND CLIP
---+-----------------------------------------------------------------
K | P2 & P3 & !P5: 1,2 EFPA(CD-Req) WF_CD
| P2 & !P3 & !P5: 1,2 EFPA(no CD) IDLELI
| !P2 & !P5: 1,2 EFNA IDLELI
| P2 & !P3 & P5: 1,2,5 EFPA(no CD) IDLELI
| !P2 & P5: 1,2,5 EFNA IDLELI
| P2 & P3 & P5: 1,2,5 EFPA(CD-Req) WF_CD
---+-----------------------------------------------------------------
L | 1,2,10 F_NERP_IND RTRP
---+-----------------------------------------------------------------
M | 1,2 RTR IDLELI
---+-----------------------------------------------------------------
U | User Error UE
---------------------------------------------------------------------
---+-----------------------------------------------------------------
L | 1,2,10 F_NERP_IND RTRP
---+-----------------------------------------------------------------
M | 1,2 RTR IDLELI
---+-----------------------------------------------------------------
U | User Error UE
---------------------------------------------------------------------
Predicate P1: (I.SFID.Restart-pos > 0 AND V.Restart = No) OR (V.Mode
= Sender-only)
Predicate P1: (I.SFID.Restart-pos > 0 AND V.Restart = No) OR (V.Mode
= Sender-only)
Note: Invalid Start File command.
注意：启动文件命令无效。
Predicate P2: Positive Response
谓词P2：肯定应答
Predicate P3: I.F_CLOSE_FILE_RS(+).Speaker = Yes
Predicate P3: I.F_CLOSE_FILE_RS(+).Speaker = Yes
Predicate P4: I.F_START_FILE_RS(+).Restart-pos > V.Restart
Predicate P4: I.F_START_FILE_RS(+).Restart-pos > V.Restart
Predicate P5: Special logic is used
谓词P5：使用特殊逻辑
Predicate P6: V.Credit_L - 1 < 0
Predicate P6: V.Credit_L - 1 < 0
Note: Protocol Error because the Speaker has exceeded its available transmission credit.
注意：协议错误，因为扬声器已超过其可用传输信用。
Predicate P7: V.Credit_L - 1 = 0
Predicate P7: V.Credit_L - 1 = 0
Note: The Speaker's credit must be reset before it can send further Data Exchange Buffers.
注意：在发送进一步的数据交换缓冲区之前，必须重置演讲者的信用。
Predicate P8: The calculus of the received CRC indicates an error
谓词P8：接收到的CRC的演算指示错误
Action 1: Stop inactivity timer
操作1：停止非活动计时器
Action 2: Start inactivity timer
操作2：启动非活动计时器
Action 3: Build F_START_FILE_IND from I.SFID V.Restart-pos = I.SFID.Restart-pos
操作3：从I.SFID V.Restart-pos=I.SFID.Restart-pos生成启动文件
Action 4: Build F_EERP_IND from I.EERP
操作4：从I.EERP构建F_EERP_IND
Action 5: Add special logic header to the command to be sent to the Speaker
动作5：将特殊逻辑头添加到要发送给扬声器的命令中
Action 6: Suppress the special logic header from the data buffer before giving it to the user
动作6：在将特殊逻辑头提供给用户之前，先从数据缓冲区中抑制它
Action 7: V.Credit_L = V.Credit_L - 1
Action 7: V.Credit_L = V.Credit_L - 1
Action 8: V.Credit_L = V.Window
行动8:V.Credit\u L=V.Window
Action 10: Build F_NERP_IND from I.NERP
行动10：从I.NERP构建F_NERP_IND
Note 1: Flow control in case of reception.
注1：接收时的流量控制。
The ODETTE-FTP Listener must periodically send new credit to the Speaker. The timing of this operation will depend on:
ODETTE-FTP侦听器必须定期向演讲者发送新信用。此操作的时间取决于：
1. The User Monitor's capacity to receive data. 2. The number of buffers available to ODETTE-FTP. 3. The Speaker's available credit, which must be equal to zero.
1. 用户监视器接收数据的能力。2.ODETTE-FTP可用的缓冲区数。3.演讲者的可用信用，必须等于零。
Consider an ODETTE-FTP entity that has sent a Start File (SFID) command and entered the Open Out Pending (OPOP) state. Its response on receiving a Positive Answer (SFPA) is documented in Speaker State Table 1, which shows that transition 'K' should be applied and is interpreted as follows:
考虑一个ODETTE-FTP实体，它已经发送了一个启动文件（SFID）命令，并进入了打开的待机状态（OPop'）状态。其在收到肯定回答（SFPA）时的响应记录在说话人状态表1中，表1显示应应用过渡“K”，并解释如下：
if (I.SFPA.Restart-pos > V.Restart-pos) then
begin // invalid restart
Actions: Stop inactivity timer, // reset timer
Start inactivity timer;
Output: ESID(R=02), // to peer ODETTE-FTP
F_ABORT_IND(R,AO=L); // to User Monitor
New State: WF_NDISC;
end
else begin
Actions: Stop inactivity timer, // reset timer
Start inactivity timer;
Build F_START_FILE_CF(+) from I.SFPA
V.Credit_S = V.Window // initialise credit
Output: F_START_FILE_CF(+); // to User Monitor
New State: OPO;
end
if (I.SFPA.Restart-pos > V.Restart-pos) then
begin // invalid restart
Actions: Stop inactivity timer, // reset timer
Start inactivity timer;
Output: ESID(R=02), // to peer ODETTE-FTP
F_ABORT_IND(R,AO=L); // to User Monitor
New State: WF_NDISC;
end
else begin
Actions: Stop inactivity timer, // reset timer
Start inactivity timer;
Build F_START_FILE_CF(+) from I.SFPA
V.Credit_S = V.Window // initialise credit
Output: F_START_FILE_CF(+); // to User Monitor
New State: OPO;
end
ODETTE-FTP checks the restart position in the received Start File Positive Answer (SFPA) command. If it is invalid, it aborts the session by sending an End Session (ESID) command to its peer and an Abort indication (F_ABORT_IND) to its User Monitor. If the restart position is valid, a Start File confirmation (F_START_FILE_CF) is built and sent to the User Monitor, the credit window is initialised, and the Open Out (OPO) state is entered.
ODETTE-FTP检查收到的启动文件肯定应答（SFPA）命令中的重启位置。如果无效，它将通过向其对等方发送结束会话（ESID）命令和向其用户监视器发送中止指示（F_Abort_IND）来中止会话。如果重新启动位置有效，则生成启动文件确认（F_Start_File_CF）并发送给用户监视器，初始化信用窗口，并进入开放（OPO）状态。
The choice of algorithms to use for security or compression between partners is for bilateral agreement outside of ODETTE-FTP.
合作伙伴之间用于安全或压缩的算法的选择是为了在ODETTE-FTP之外达成双边协议。
The algorithms for symmetric and asymmetric cryptography and hashing are represented by a coded value, the cipher suite:
对称和非对称加密和散列的算法由编码值表示，密码套件：
Cipher Suite Symmetric Asymmetric Hashing
------------ ----------------- ------------ -------
Cipher Suite Symmetric Asymmetric Hashing
------------ ----------------- ------------ -------
01 3DES_EDE_CBC_3KEY RSA_PKCS1_15 SHA-1 02 AES_256_CBC RSA_PKCS1_15 SHA-1
01 3DES_EDE_CBC_3KEY RSA_PKCS1_15 SHA-1 02 AES_256_CBC RSA_PKCS1_15 SHA-1
Support of all cipher suites listed here is mandatory.
必须支持此处列出的所有密码套件。
The certificates used must be [X.509] certificates.
使用的证书必须是[X.509]证书。
TripleDES is using Cipher Block Chaining (CBC) mode for added security and uses the Encryption Decryption Encryption (EDE) process with 3 different 64-bit keys.
TripleDES使用密码块链接（CBC）模式来增加安全性，并使用3个不同的64位密钥的加密-解密-加密（EDE）过程。
RSA padding is as defined in [PKCS#1].
RSA填充的定义见[PKCS#1]。
AES is using a 256-bit key in CBC mode.
AES在CBC模式下使用256位密钥。
An extended list of optional cipher suites may be used (Section 10.3), but there is no guarantee that two communicating ODETTE-FTP entities would both support these optional cipher suites.
可以使用可选密码套件的扩展列表（第10.3节），但不能保证两个通信的ODETTE-FTP实体都支持这些可选密码套件。
The algorithms and file enveloping formats available in ODETTE-FTP may be extended outside of this document.
ODETTE-FTP中可用的算法和文件封装格式可扩展到本文件之外。
An up-to-date list of cipher suite values for use in ODETTE-FTP is maintained by ODETTE International, and published on their website at www.odette.org.
ODETTE International维护用于ODETTE-FTP的密码套件值的最新列表，并在其网站www.ODETTE.org上发布。
Certificates and certificate revocation lists may be exchanged as [CMS] enveloped files. It is therefore valid to exchange a [CMS] file that is neither encrypted, compressed, nor signed. It is an application implementation issue to determine the correct course of action on receipt of such a file.
证书和证书撤销列表可以作为[CMS]信封文件交换。因此，交换既没有加密、压缩也没有签名的[CMS]文件是有效的。在收到此类文件时，确定正确的操作过程是一个应用程序实现问题。
ODETTE-FTP security requires the use of [X.509] certificates. If no security options are agreed for use, the send and receive passwords are sent in plain text. Whilst this is acceptable over X.25 and ISDN networks, this is a risky practice over insecure public networks such as the Internet.
ODETTE-FTP安全性要求使用[X.509]证书。如果不同意使用安全选项，发送和接收密码将以纯文本形式发送。虽然这在X.25和ISDN网络上是可以接受的，但在不安全的公共网络（如互联网）上，这是一种危险的做法。
All, some, or none of the security options available in ODETTE-FTP may be used. No recommendations for the use of these options are provided in this specification. Whilst use of the highest-strength encryption algorithms may seem admirable, there is often a performance tradeoff to be made, and signing all files and acknowledgements has potential legal implications that should be considered.
可以使用ODETTE-FTP中的所有、部分或任何安全选项。本规范中未提供使用这些选项的建议。虽然使用最高强度的加密算法似乎令人钦佩，但通常需要进行性能权衡，并且签署所有文件和确认具有潜在的法律影响，应予以考虑。
It should be noted that whilst the security measures ensure that an ODETTE-FTP partner is authenticated, it does not necessarily mean that the partner is authorised. Having proven the identity of a partner, it is an application issue to decide whether that partner is allowed to connect or exchange files.
应注意的是，虽然安全措施确保ODETTE-FTP合作伙伴经过认证，但这并不一定意味着该合作伙伴已获得授权。在证明了合作伙伴的身份后，决定是否允许该合作伙伴连接或交换文件是一个应用程序问题。
Extracted from [RFC3850]:
摘自[RFC3850]：
"When processing certificates, there are many situations where the processing might fail. Because the processing may be done by a user agent, a security gateway, or other program, there is no single way to handle such failures. Just because the methods to handle the failures have not been listed, however, the reader should not assume that they are not important. The opposite is true: if a certificate is not provably valid and associated with the message, the processing software should take immediate and noticeable steps to inform the end user about it.
“在处理证书时，有许多情况下处理可能会失败。由于处理可能由用户代理、安全网关或其他程序完成，因此没有单一的方法来处理此类失败。但是，仅仅因为没有列出处理失败的方法，读者不应假定它们是正确的不重要。事实正好相反：如果证书不可证明有效且与消息关联，则处理软件应立即采取明显的步骤通知最终用户。
Some of the many situations in which signature and certificate checking might fail include the following:
签名和证书检查可能失败的许多情况包括：
No certificate chain leads to a trusted CA No ability to check the Certificate Revocation List (CRL) for a certificate An invalid CRL was received The CRL being checked is expired The certificate is expired The certificate has been revoked
没有证书链导致受信任的CA无法检查证书吊销列表（CRL）中的证书接收到无效的CRL正在检查的CRL已过期证书已过期证书已被吊销
There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly, and to decide what to do if the check fails. See RFC 3280 for additional information on certificate path validation."
当然，在其他情况下，证书可能是无效的，处理软件有责任彻底检查所有证书，并决定如果检查失败怎么办。有关证书路径验证的更多信息，请参阅RFC 3280。“
The push / pull nature of ODETTE-FTP means that a party can make an outbound connection from behind a firewall to another party and exchange files in both directions. There is no need for both partners to open ports on their firewalls to allow incoming connections; only one party needs to allow incoming connections.
ODETTE-FTP的推/拉特性意味着一方可以从防火墙后面建立到另一方的出站连接，并在两个方向上交换文件。双方无需在防火墙上打开端口以允许传入连接；只有一方需要允许传入连接。
See Section 1.7 for a discussion of the benefits of session security [TLS] versus file security.
有关会话安全性[TLS]与文件安全性的好处的讨论，请参见第1.7节。
This example demonstrates the mapping of a Virtual File into a sequence of ODETTE-FTP Data Exchange Buffers.
此示例演示如何将虚拟文件映射到ODETTE-FTP数据交换缓冲区序列。
Each line in this extract from 'The Rime of the Ancient Mariner' by Coleridge [RIME] is separated by CR-LFs in a file that is being transmitted as a T format file.
柯勒律治的《古代水手的雾凇》摘录中的每一行都由CR LFs分隔，并以T格式文件传输。
It is an ancient Mariner, And he stoppeth one of three. "By thy long grey beard and glittering eye, Now wherefore stopp'st thou me?
这是一个古代水手，他阻止了三个中的一个。“凭你那长长的灰胡子和闪闪发光的眼睛，你为什么要阻止我？
"The Bridegroom's doors are opened wide, And I am next of kin; The guests are met, the feast is set: May'st hear the merry din."
“新郎的门开得很大，我是他的近亲；客人们都来了，宴会已经安排好了。我可以听到欢乐的喧闹声。”
He holds him with his skinny hand, "There was a ship," quoth he. "Hold off! unhand me, grey-beard loon!" Eftsoons his hand dropt he.
他用瘦削的手握住他，“有一艘船，”他引用道。“等等！放开我，灰胡子呆子！”埃夫特松了松手。
He holds him with his glittering eye-- The Wedding-Guest stood still, And listens like a three years; child: The Mariner hath his will.
他用闪闪发光的眼睛抱住他——婚礼上的客人一动不动地站着，像听了三年似的；孩子：水手有他的意志。
The Wedding-Guest sat on a stone: He cannot chuse but hear; And thus spake on that ancient man, The bright-eyed Mariner.
婚礼的客人坐在一块石头上：他不能不听到；就这样谈到了那个目光明亮的水手。
The ship was cheered, the harbour cleared, Merrily did we drop Below the kirk, below the hill, Below the light-house top.
船被欢呼，港口被清理干净，我们高兴地降落在柯克河下，山下，灯塔顶下。
The Exchange Buffers below were built from the above. The top line of each represents the ASCII code, while the two lines below give the hexadecimal value.
下面的Exchange缓冲区是从上面构建的。每行的顶行表示ASCII码，而下面的两行表示十六进制值。
Note that:
请注意：
. The "D" at the beginning of each Exchange Buffer is the command code.
. 每个Exchange缓冲区开头的“D”是命令代码。
. The "?" preceding each subrecord is the header octet (see the hexadecimal value).
. 每个子记录前面的“？”是头八位字节（参见十六进制值）。
Exchange Buffer 1
交换缓冲区1
D?It is an ancient Mariner,..And he stoppeth one of three..."By
4347267266266666672467666720046626627767767626662662767662002472
4F9409301E01E395E40D129E52CDA1E4085034F005480FE50F6048255EDA2290
D?It is an ancient Mariner,..And he stoppeth one of three..."By
4347267266266666672467666720046626627767767626662662767662002472
4F9409301E01E395E40D129E52CDA1E4085034F005480FE50F6048255EDA2290
t?hy long grey beard and glittering eye,..Now wherefore stopp'st
7367266662676726667626662666776766626762004672766766676277677277
4F890CFE70725902512401E407C944529E70595CDAEF70785256F25034F00734
t?hy long grey beard and glittering eye,..Now wherefore stopp'st
7367266662676726667626662666776766626762004672766766676277677277
4F890CFE70725902512401E407C944529E70595CDAEF70785256F25034F00734
?thou me?...."The Bridegroom's doors are opened wide,..And I am
2376672663000025662476666766627266677267626766662766620046624266
0F48F50D5FDADA248502294572FFD7304FF2301250F05E5407945CDA1E40901D
?thou me?...."The Bridegroom's doors are opened wide,..And I am
2376672663000025662476666766627266677267626766662766620046624266
0F48F50D5FDADA248502294572FFD7304FF2301250F05E5407945CDA1E40901D
?next of kin;..The guests are met, the feast is set:..May'st he
2366772662666300566267677726762667227662666772672767300467277266
0FE5840F60B9EBDA485075534301250D54C04850651340930354ADAD19734085
?next of kin;..The guests are met, the feast is set:..May'st he
2366772662666300566267677726762667227662666772672767300467277266
0FE5840F60B9EBDA485075534301250D54C04850651340930354ADAD19734085
a?r the merry din."....He holds him with his skinny hand,.."Ther
6372766266777266622000046266667266627676266727666672666620025667
1F204850D5229049EE2DADA8508FC43089D07948089303B9EE9081E4CDA24852
a?r the merry din."....He holds him with his skinny hand,.."Ther
6372766266777266622000046266667266627676266727666672666620025667
1F204850D5229049EE2DADA8508FC43089D07948089303B9EE9081E4CDA24852
e? was a ship," quoth he..."Hold off! unhand me, grey-beard loon
6327672627667222776762662002466626662276666626622676726667626666
5F07130103890C2015F48085EDA28FC40F66105E81E40D5C07259D251240CFFE
e? was a ship," quoth he..."Hold off! unhand me, grey-beard loon
6327672627667222776762662002466626662276666626622676726667626666
5F07130103890C2015F48085EDA28FC40F66105E81E40D5C07259D251240CFFE
!?"..Eftsoons his hand dropt he.....He holds him with his glitte
2320046776667266726666267677266200004626666726662767626672666776
1F2DA5643FFE30893081E4042F04085EDADA8508FC43089D07948089307C9445
!?"..Eftsoons his hand dropt he.....He holds him with his glitte
2320046776667266726666267677266200004626666726662767626672666776
1F2DA5643FFE30893081E4042F04085EDADA8508FC43089D07948089307C9445
r?ing eye--..The Wedding-Guest stood still,..And listens like a
7366626762200566256666662476772776662776662004662667766726666262
2F9E70595DDDA485075449E7D75534034FF40349CCCDA1E40C9345E30C9B5010
r?ing eye--..The Wedding-Guest stood still,..And listens like a
7366626762200566256666662476772776662776662004662667766726666262
2F9E70595DDDA485075449E7D75534034FF40349CCCDA1E40C9345E30C9B5010
t?hree years; child:..The Mariner hath his will.....The Wedding-
7367662766773266666300566246766672667626672766620000566256666662
4F8255095123B0389C4ADA4850D129E52081480893079CCEDADA485075449E7D
t?hree years; child:..The Mariner hath his will.....The Wedding-
7367662766773266666300566246766672667626672766620000566256666662
4F8255095123B0389C4ADA4850D129E52081480893079CCEDADA485075449E7D
G?uest sat on a stone:..He cannot chuse but hear;..And thus spak
4376772767266262776663004626666672667762677266673004662767727766
7F553403140FE01034FE5ADA85031EEF4038535025408512BDA1E4048530301B
G?uest sat on a stone:..He cannot chuse but hear;..And thus spak
4376772767266262776663004626666672667762677266673004662767727766
7F553403140FE01034FE5ADA85031EEF4038535025408512BDA1E4048530301B
e? on that ancient man,..The bright-eyed Mariner.....The ship wa
6326627667266666672666200566267666726766246766672000056627667276
5F0FE0481401E395E40D1ECDA4850229784D59540D129E52EDADA48503890071
e? on that ancient man,..The bright-eyed Mariner.....The ship wa
6326627667266666672666200566267666726766246766672000056627667276
5F0FE0481401E395E40D1ECDA4850229784D59540D129E52EDADA48503890071
s? cheered, the harbour cleared,..Merrily did we drop..Below the
7326666766227662667667726666766200467766726662762676700466672766
3F03855254C048508122F5203C51254CDAD5229C90494075042F0DA25CF70485
s? cheered, the harbour cleared,..Merrily did we drop..Below the
7326666766227662667667726666766200467766726662762676700466672766
3F03855254C048508122F5203C51254CDAD5229C90494075042F0DA25CF70485
.kirk, below the hill,..Below the light-house top...
2B667622666672766266662004666727662666672667762767200
03B92BC025CF70485089CCCDA25CF704850C9784D8F53504F0EDA
.kirk, below the hill,..Below the light-house top...
2B667622666672766266662004666727662666672667762767200
03B92BC025CF70485089CCCDA25CF704850C9784D8F53504F0EDA
o-----------------------------------------------------------------o
| | 7| 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
| | B -+-----+-----+-----+-----+-----+-----+-----+-----|
| | I 6| 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |
| | T -+-----+-----+-----+-----+-----+-----+-----+-----|
| | 5| 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
| |----+-----+-----+-----+-----+-----+-----+-----+-----|
| | | | | | | | | | |
| | | | | | | | | | |
|------------| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| BIT | | | | | | | | | |
| 4 3 2 1 | | | | | | | | | |
|============o====o=====+=====+=====+=====+=====+=====+=====+=====|
| 0 0 0 0 | 0 | | | SP | 0 | | P | | |
|------------|----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 0 0 1 | 1 | | | | 1 | A | Q | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 0 1 0 | 2 | | | | 2 | B | R | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 0 1 1 | 3 | | | | 3 | C | S | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 0 0 | 4 | | | | 4 | D | T | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 0 1 | 5 | | | | 5 | E | U | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 1 0 | 6 | | | & | 6 | F | V | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 1 1 | 7 | | | | 7 | G | W | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 0 0 | 8 | | | ( | 8 | H | X | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 0 1 | 9 | | | ) | 9 | I | Y | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 1 0 | 10 | | | | | J | Z | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 1 1 | 11 | | | | | K | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 0 0 | 12 | | | | | L | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 0 1 | 13 | | | - | | M | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 1 0 | 14 | | | . | | N | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 1 1 | 15 | | | / | | O | | | |
o-----------------------------------------------------------------o
o-----------------------------------------------------------------o
| | 7| 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
| | B -+-----+-----+-----+-----+-----+-----+-----+-----|
| | I 6| 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |
| | T -+-----+-----+-----+-----+-----+-----+-----+-----|
| | 5| 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
| |----+-----+-----+-----+-----+-----+-----+-----+-----|
| | | | | | | | | | |
| | | | | | | | | | |
|------------| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| BIT | | | | | | | | | |
| 4 3 2 1 | | | | | | | | | |
|============o====o=====+=====+=====+=====+=====+=====+=====+=====|
| 0 0 0 0 | 0 | | | SP | 0 | | P | | |
|------------|----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 0 0 1 | 1 | | | | 1 | A | Q | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 0 1 0 | 2 | | | | 2 | B | R | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 0 1 1 | 3 | | | | 3 | C | S | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 0 0 | 4 | | | | 4 | D | T | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 0 1 | 5 | | | | 5 | E | U | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 1 0 | 6 | | | & | 6 | F | V | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 1 1 | 7 | | | | 7 | G | W | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 0 0 | 8 | | | ( | 8 | H | X | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 0 1 | 9 | | | ) | 9 | I | Y | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 1 0 | 10 | | | | | J | Z | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 1 1 | 11 | | | | | K | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 0 0 | 12 | | | | | L | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 0 1 | 13 | | | - | | M | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 1 0 | 14 | | | . | | N | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 1 1 | 15 | | | / | | O | | | |
o-----------------------------------------------------------------o
The International Organization for Standardization (ISO) Open Systems Interconnection (OSI) model is the basis for ODETTE-FTP.
国际标准化组织（ISO）开放系统互连（OSI）模型是ODETE-FTP的基础。
ODETTE-FTP covers levels 4 to 7, and originally CCITT X.25 was the only recommended telecommunication protocol for OSI's layers 1, 2, 3.
ODETTE-FTP涵盖4至7级，最初CCITT X.25是OSI第1、2、3层的唯一推荐电信协议。
ISO Reference Model:
ISO参考模型：
+------------------------------+ <==== File Service
| Level-7 FTP application |
|------------------------------|
| Level-6 FTP presentation |
|------------------------------|
| Level-5 FTP session |
|------------------------------|
| Level-4 FTP transport |
|------------------------------| <==== Network Service
| Level-3 X.25 |
|------------------------------|
| Level-2 X.25 |
|------------------------------|
| Level-1 X.25 |
+------------------------------+
+------------------------------+ <==== File Service
| Level-7 FTP application |
|------------------------------|
| Level-6 FTP presentation |
|------------------------------|
| Level-5 FTP session |
|------------------------------|
| Level-4 FTP transport |
|------------------------------| <==== Network Service
| Level-3 X.25 |
|------------------------------|
| Level-2 X.25 |
|------------------------------|
| Level-1 X.25 |
+------------------------------+
When an X.25 call is made over a PSDN, the Network User Address (NUA) of the destination must be specified in order that the PTT may route the call. The call placed is directed to the termination equipment upon the user's premises.
当通过PSDN进行X.25呼叫时，必须指定目的地的网络用户地址（NUA），以便PTT可以路由呼叫。发出的呼叫被定向到用户所在地的终端设备。
It is possible to provide extra information in the Call Request Packet in addition to the mandatory NUA required by the PTT.
除了PTT要求的强制性NUA之外，还可以在呼叫请求包中提供额外信息。
This extra information may be of 2 kinds:
此额外信息可能有两种：
(a) A subaddress:
(a) 子地址：
It is simply an extension to the address and it is put into the called address field of the Call Request Packet. This information (Address + Subaddress) is taken from the destination address field of the F_CONNECT_RQ; therefore, from the user's point of view, there is no distinction between the main address and subaddress parts.
它只是地址的一个扩展，被放入呼叫请求包的被叫地址字段中。此信息（地址+子地址）取自F_CONNECT_RQ的目标地址字段；因此，从用户的角度来看，主地址和子地址部分之间没有区别。
(b) User data:
(b) 用户数据：
There is no standard for user data. Moreover, there is no information in the F_CONNECT_RQ from which the ODETTE-entity may derive user data to be put in the N_CONNECT_RQ; therefore, user data shall not be used.
用户数据没有标准。此外，在F_CONNECT_RQ中不存在奥德特实体可从中导出要放入N_CONNECT_RQ中的用户数据的信息；因此，不得使用用户数据。
The SSID field SSIDSPEC specifies whether special logic must be applied (Y (yes) or N (no)) to the Data Exchange Buffer before the ODETTE-FTP moves the data into the NSDU (Network Service Data Unit) and passes control to the Network Service.
SSID字段SSIDSPEC指定在ODETE-FTP将数据移动到NSDU（网络服务数据单元）并将控制权传递给网络服务之前，是否必须对数据交换缓冲区应用特殊逻辑（Y（是）或N（否）。
This logic is not applied to SSRM and SSID commands.
此逻辑不适用于SSRM和SSID命令。
The "special-logic" parameter was created in order to allow the use of ODETTE-FTP over asynchronous links. The "special-logic" could be needed to enable terminals to access an X.25 network via an asynchronous entry (through a PAD: Packet Assembly / Disassembly). The "special-logic" is not needed in case of a whole X.25 connection. This "special-logic" realises a CRC function in order to detect errors due to the asynchronous medium.
创建“特殊逻辑”参数是为了允许在异步链路上使用ODETTE-FTP。可能需要“特殊逻辑”使终端能够通过异步条目（通过PAD：数据包组装/拆卸）访问X.25网络。在整个X.25连接的情况下，不需要“特殊逻辑”。这种“特殊逻辑”实现CRC功能，以便检测由异步介质引起的错误。
Negotiation of the "special-logic" parameter in the SSID command is as follows:
SSID命令中“特殊逻辑”参数的协商如下：
SSID SSID
-----------------------------------------------
SSID SSID
-----------------------------------------------
special-logic=yes --------------------->
special-logic=yes --------------------->
<------------------------------------ special-logic=yes
or
<------------------------------------ special-logic=no
<------------------------------------ special-logic=yes
or
<------------------------------------ special-logic=no
special-logic=no ---------------------->
special-logic=no ---------------------->
<------------------------------------ special-logic=no
<------------------------------------ special-logic=no
This logic is activated when the "special-logic" parameter in the SSID specifies Y (yes).
当SSID中的“特殊逻辑”参数指定Y（是）时，此逻辑被激活。
Special logic processing, when activated, will function within level 4 of the OSI model.
特殊逻辑处理在激活时，将在OSI模型的第4级内运行。
+------------------------------+ <==== File Service
| Level-7 FTP application |
|------------------------------|
| Level-6 FTP presentation |
|------------------------------|
| Level-5 FTP session |
|------------------------------|
| Level-4 FTP transport |
| SPECIAL LOGIC PROCESSING |
|------------------------------| <==== Network Service
| Level-3 X.25 |
|------------------------------|
| Level-2 X.25 |
|------------------------------|
| Level-1 X.25 |
+------------------------------+
+------------------------------+ <==== File Service
| Level-7 FTP application |
|------------------------------|
| Level-6 FTP presentation |
|------------------------------|
| Level-5 FTP session |
|------------------------------|
| Level-4 FTP transport |
| SPECIAL LOGIC PROCESSING |
|------------------------------| <==== Network Service
| Level-3 X.25 |
|------------------------------|
| Level-2 X.25 |
|------------------------------|
| Level-1 X.25 |
+------------------------------+
When transmitting an Exchange Buffer and special logic is active, layer 4 will wrap the Exchange Buffer in synchronization and delineation characters, then protect the data integrity by means of a block checksum (BCS). When receiving an Exchange Buffer and special logic is active, layer 4 will remove such things as synchronization and delineation characters, etc., before passing the Exchange Buffer to the higher layers.
当传输交换缓冲区且特殊逻辑处于活动状态时，第4层将以同步和描绘字符包装交换缓冲区，然后通过块校验和（BCS）保护数据完整性。当接收到交换缓冲区且特殊逻辑处于活动状态时，第4层将在将交换缓冲区传递给更高层之前删除同步和描绘字符等内容。
Each envelope has a 1-byte header prefixed to it, and a 2-byte checksum appended to the end. The checksum is derived in a manner specified in the ISO DIS 8073 TRANSPORT LAYER documentation.
每个信封都有一个前缀为1字节的标题，结尾附加一个2字节的校验和。校验和以ISO DIS 8073传输层文档中规定的方式导出。
The layout of the data buffer will be structured as follows:
数据缓冲区的布局结构如下：
+------------------------------------------------------------------+
| S | B | | B | C |
| T | S | COMPLETE EXCHANGE BUFFER (CEB) | C | / |
| X | N | | S | R |
+------------------------------------------------------------------+
A A A A
| | | |
| +------------- Block sequence number | |
| | |
+----------------- Synchronization character | |
| |
Block checksum -----------------------+ |
|
Delineation character --------------------+
+------------------------------------------------------------------+
| S | B | | B | C |
| T | S | COMPLETE EXCHANGE BUFFER (CEB) | C | / |
| X | N | | S | R |
+------------------------------------------------------------------+
A A A A
| | | |
| +------------- Block sequence number | |
| | |
+----------------- Synchronization character | |
| |
Block checksum -----------------------+ |
|
Delineation character --------------------+
The envelope is initialised with an STX and the checksum variables are set to 0. The leading STX is not protected by the checksum calculation but is explicitly protected by a character compare at the receiver's end. The Exchange Buffer is processed character by character. As each character is removed from the Exchange Buffer, it is put through the checksum calculation and then, prior to its insertion in the envelope, it is put through the Shift-out transparency logic, which will result in either one or two characters being inserted. When the contents of the Exchange Buffer have been entirely processed, then the checksum variables are brought up to date by inserting two X'00's through the checksum calculator and the two resultant checksum characters forwarded to the Shift-out transparency logic for insertion into the envelope. Finally, a carriage return (CR) is appended to the envelope. The segment is now ready for transmission to line.
信封用STX初始化，校验和变量设置为0。前导STX不受校验和计算的保护，但受接收器端字符比较的明确保护。交换缓冲区是逐字符处理的。当每个字符从Exchange缓冲区中删除时，都会对其进行校验和计算，然后在将其插入信封之前，会对其进行移出透明逻辑，这将导致插入一个或两个字符。当交换缓冲区的内容完全处理完毕后，通过校验和计算器插入两个X'00，并将两个结果校验和字符转发给移出透明逻辑以插入信封，从而使校验和变量更新。最后，在信封上附加回车符（CR）。该段现在已准备好传输到线路。
Upon receipt of a valid envelope that has the correct sequence number, the host should increment his sequence number register ready for the next transmission.
收到具有正确序列号的有效信封后，主机应增加其序列号寄存器，以备下次传输。
The receiver will initialise his receiving buffer area upon receipt of an STX character, place the STX at the beginning of the buffer, and reset checksum variables. All subsequent characters are processed using Shift-out logic before they are inserted into the buffer, at which point they will NOT be processed by the checksum calculator, although the character following the Shift-out (after subtracting X'20') will be. The checksum characters themselves will be processed by the checksum calculator by virtue of the design of the checksum algorithm.
接收器将在收到STX字符后初始化其接收缓冲区，将STX置于缓冲区的开头，并重置校验和变量。所有后续字符在插入缓冲区之前都使用移位逻辑进行处理，此时校验和计算器将不处理这些字符，尽管移位后的字符（减去X'20'）将被删除。通过设计校验和算法，校验和计算器将处理校验和字符本身。
The error correction scheme is implemented by the definition of three timers and the use of an ASCII NAK (Negative Acknowledgement) character followed by a C/R. The <NAK><C/R> will flow between the two session partners, but only as a consequence of previous bad data.
纠错方案通过定义三个计时器和使用ASCII NAK（否定确认）字符，后跟C/R来实现。<NAK><C/R>将在两个会话伙伴之间流动，但仅作为先前坏数据的结果。
A user of the error recovery correcting extension must always work with a credit value of 1. This can be forced upon any session partner at SSID negotiation. The effect will be to force a simple half-duplex flip-flop protocol.
错误恢复更正扩展的用户必须始终使用信用值1。这可以在SSID协商时强制给任何会话伙伴。其效果将是强制使用一个简单的半双工触发器协议。
Upon receipt of a bad block, send <NAK><C/R> to the session partner.
收到坏块后，向会话伙伴发送<NAK><C/R>。
Upon receipt of a <NAK><C/R>, a session partner should retransmit the last block in its entirety.
在收到<NAK><C/R>后，会话伙伴应全部重新传输最后一个块。
The majority of error conditions will be detected by a bad BCS sequence. However, certain conditions cannot be so detected. For example, a corrupt C/R will mean that the receiver will not know that the end of a block has been reached. No matter how long he waits, no more data will come from the sender. Thus, a timer is the only way to detect this type of corruption. There are three timers needed to detect all possible malignant conditions of this type.
大多数错误情况将由错误的BCS序列检测。但是，某些情况无法检测到。例如，损坏的C/R将意味着接收器将不知道已到达块的末尾。无论他等待多长时间，都不会有更多的数据来自发送者。因此，计时器是检测此类损坏的唯一方法。需要三个计时器来检测这种类型的所有可能的恶性疾病。
T1 - Exchange Buffer Time Out (Inactivity or Response) T2 - Inter Character Time Out T3 - Data Carrier Detect Loss Time Out
T1-交换缓冲区超时（不活动或响应）T2-字符间超时T3-数据载波检测丢失超时
The three timers are in addition to the timer defined in the original protocol.
这三个定时器是原始协议中定义的定时器的补充。
TIMER T1 - RESPONSE TIME OUT (DEFAULT = 45 SECONDS):
计时器T1-响应超时（默认值为45秒）：
Used to detect a high-level block Time Out, e.g., the Time Out between an SFID and its associated SFPA or SFNA response.
用于检测高级块超时，例如，SFID与其相关SFPA或SFNA响应之间的超时。
Started - It is started after the last character of an exchange buffer has been sent to the line.
已启动-在exchange缓冲区的最后一个字符发送到行后启动。
Stopped - It is stopped when an STX has been received.
已停止-收到STX后停止。
Expiry - Retransmit the whole block again, until such time as the retry limit has been reached.
到期-再次重新传输整个数据块，直到达到重试限制。
TIMER T2 - INTER CHARACTER TIME OUT (DEFAULT = 7 SECONDS):
计时器T2-字符间超时（默认值为7秒）：
Used to detect errors in the reception of individual characters.
用于检测单个字符接收中的错误。
Started - For an asynchronous entity, it is started upon receipt of each character while in synchronisation mode. For an X.25 entity, it is started after a received block that did not terminate an Exchange Buffer.
已启动-对于异步实体，它在同步模式下收到每个字符后启动。对于X.25实体，它在接收到未终止Exchange缓冲区的块之后启动。
Stopped - Upon receipt of the next character.
停止-在收到下一个字符时。
Expiry - Send a <NAK><C/R>, drop out of synchronised mode, and go back and listen to line.
到期-发送<NAK><C/R>，退出同步模式，然后返回并收听线路。
TIMER T3 - DATA CARRIER TEMPORARY LOSS (DEFAULT = 1 SECOND):
计时器T3-数据载体临时丢失（默认值=1秒）：
Used by an asynchronous entity only and is used to detect a temporary carrier failure.
仅由异步实体使用，用于检测临时载波故障。
Started - When DCD (Data Carrier Detect) is lost.
已启动-当DCD（数据载波检测）丢失时。
Stopped - When DCD is regained.
停止-恢复DCD时。
Expiry - Disconnect the session.
到期-断开会话连接。
Data corruption when it occurs can be categorised in one of five ways:
发生数据损坏时，可按以下五种方式之一进行分类：
(1) CORRUPT STX (START OF TEXT)
(1) 损坏的STX（文本开头）
In this situation the STX is not seen and synchronisation is not achieved. The terminating C/R is received out of synchronisation and hence the block is not seen by the receiver. A <NAK><C/R> is transmitted to the sender to indicate this. The sender should then retransmit the last block (each implementation will need to set a retry limit to be used for the number of consecutive times it attempts to retransmit a block -- a default limit of 5 is recommended). All data received outside synchronisation (except <NAK><C/R>) are ignored.
在这种情况下，无法看到STX，也无法实现同步。终端C/R接收不同步，因此接收器看不到该块。一个<NAK><C/R>被发送到发送方以指示这一点。然后，发送方应该重新传输最后一个块（每个实现需要设置一个重试限制，用于它尝试重新传输块的连续次数——建议默认限制为5）。在同步之外接收的所有数据（除了<NAK><C/R>）都将被忽略。
(A) (B)
（A） （B）
Dropped Start of Text (STX)
删除的文本开头（STX）
+-------------------------+
| | B | | B | C |
-----| | S | CEB | C | / |-----> Not sync
| | N | | S | R |
+-------------------------+
+-------------------------+
| | B | | B | C |
-----| | S | CEB | C | / |-----> Not sync
| | N | | S | R |
+-------------------------+
+-------+
| N | C |
<-----| A | / |----- Not sync
| K | R |
+-------+
+-------+
| N | C |
<-----| A | / |----- Not sync
| K | R |
+-------+
Exchange Buffer Resent
交换缓冲区重新发送
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Sync
| X | N | | S | R |
+-------------------------+
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Sync
| X | N | | S | R |
+-------------------------+
(2) CORRUPT TERMINATION (C/R)
(2) 损坏的终止（C/R）
This situation manifests itself as an extended period of synchronisation with no activity. The T2 timer will detect this condition.
这种情况表现为无活动的长时间同步。T2定时器将检测到这种情况。
(A) (B)
（A） （B）
Corrupt Carriage Return
损坏的回车
+-------------------------+
| S | B | | B | |
-----| T | S | CEB | C | |-----> No activity
| X | N | | S | |
+-------------------------+
+-------------------------+
| S | B | | B | |
-----| T | S | CEB | C | |-----> No activity
| X | N | | S | |
+-------------------------+
+-------+
| N | C | T2
<-----| A | / |----- Timed out
| K | R |
+-------+
+-------+
| N | C | T2
<-----| A | / |----- Timed out
| K | R |
+-------+
Exchange Buffer Resent
交换缓冲区重新发送
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Sync
| X | N | | S | R |
+-------------------------+
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Sync
| X | N | | S | R |
+-------------------------+
(3) BAD DATA (4) BAD BCS (BLOCK CHECK SUM)
(3) 错误数据（4）错误BCS（块校验和）
In this situation, the receiver is unable to tell whether the error is bad data or bad BCS. In either case, the response is to discard the Exchange Buffer and send a <NAK><C/R>.
在这种情况下，接收器无法判断错误是坏数据还是坏BCS。在这两种情况下，响应都是丢弃Exchange缓冲区并发送<NAK><C/R>。
(A) (B)
（A） （B）
Bad Data/BCS
坏数据/BCS
+-------------------------+
| S | B | | B | C | Bad data
-----| T | S | "%! | C | / |-----> detected
| X | N | | S | R |
+-------------------------+
+-------------------------+
| S | B | | B | C | Bad data
-----| T | S | "%! | C | / |-----> detected
| X | N | | S | R |
+-------------------------+
+-------+
| N | C |
<-----| A | / |----- Discard Block
| K | R |
+-------+
+-------+
| N | C |
<-----| A | / |----- Discard Block
| K | R |
+-------+
Exchange Buffer Resent
交换缓冲区重新发送
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Data OK
| X | N | | S | R |
+-------------------------+
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Data OK
| X | N | | S | R |
+-------------------------+
(5) BAD BLOCK SEQUENCE NUMBER (BSN)
(5) 坏块序列号（BSN）
A circular sequential number (0 up to and including 9) is assigned to transmitted Exchange Buffers. This is to aid detection of duplicate or out-of-sequence Exchange Buffers. Once a duplicate block is detected, the Exchange Buffer in question is discarded. Once an out of sequence block is detected, this should result in a protocol violation.
向传输的交换缓冲区分配一个循环序列号（0到9，包括9）。这有助于检测重复或无序的交换缓冲区。一旦检测到重复块，将丢弃有问题的Exchange缓冲区。一旦检测到无序块，这将导致协议冲突。
Example protocol sequence:
协议序列示例：
(A) (B)
（A） （B）
Exchange Buffer Being Sent
正在发送Exchange缓冲区
+-------------------------+
| S | | | B | C | Expecting
-----| T | 0 | EERP | C | / |-----> BSN=0
| X | | | S | R | Transmission
+-------------------------+
+-------------------------+
| S | | | B | C | Expecting
-----| T | 0 | EERP | C | / |-----> BSN=0
| X | | | S | R | Transmission
+-------------------------+
Exchange Buffer Being Sent
正在发送Exchange缓冲区
+-------------------------+
| S | | | B | C | Response to
<----| T | 0 | RTR | C | / |----- Previous
| X | | | S | R | Block
+-------------------------+
+-------------------------+
| S | | | B | C | Response to
<----| T | 0 | RTR | C | / |----- Previous
| X | | | S | R | Block
+-------------------------+
Exchange Buffer Being Sent
正在发送Exchange缓冲区
+-------------------------+ Expecting
| S | | | B | C | BSN=1 (Block
-----| T | 1 | SFID | C | / |- // -> lost in
| X | | | S | R | Transmission)
+-------------------------+ T1 Timed Out
+-------------------------+ Expecting
| S | | | B | C | BSN=1 (Block
-----| T | 1 | SFID | C | / |- // -> lost in
| X | | | S | R | Transmission)
+-------------------------+ T1 Timed Out
Exchange Buffer Being Sent
正在发送Exchange缓冲区
+-------------------------+
| S | | | B | C | Send last
<----| T | 0 | RTR | C | / |----- Block
| X | | | S | R | again
+-------------------------+
+-------------------------+
| S | | | B | C | Send last
<----| T | 0 | RTR | C | / |----- Block
| X | | | S | R | again
+-------------------------+
Discard Block and start Timer T1
丢弃块并启动计时器T1
T1 Timed Out
T1超时
Exchange Buffer Resent
交换缓冲区重新发送
+-------------------------+
| S | | | B | C | Expecting
-----| T | 1 | SFID | C | / |-----> BSN=1
| X | | | S | R | Block OK
+-------------------------+
+-------------------------+
| S | | | B | C | Expecting
-----| T | 1 | SFID | C | / |-----> BSN=1
| X | | | S | R | Block OK
+-------------------------+
Exchange Buffer Being Sent
正在发送Exchange缓冲区
+-------------------------+
| S | | | B | C | Response
<----| T | 1 | SFPA | C | / |----- BSN=1
| X | | | S | R | Block OK
+-------------------------+
+-------------------------+
| S | | | B | C | Response
<----| T | 1 | SFPA | C | / |----- BSN=1
| X | | | S | R | Block OK
+-------------------------+
Exchange Buffer Being Sent
正在发送Exchange缓冲区
+-------------------------+
| S | | | B | C |
-----| T | 2 | DATA | C | / |-----> Data OK
| X | | | S | R |
+-------------------------+
+-------------------------+
| S | | | B | C |
-----| T | 2 | DATA | C | / |-----> Data OK
| X | | | S | R |
+-------------------------+
Note: A credit value of 1 must be used to guarantee half-duplex flip-flop.
注：必须使用信用值1来保证半双工触发器。
The following functions will be executed in sequence:
以下功能将按顺序执行：
1. Calculation of the Block Sequence Number (BSN):
1. 块序列号（BSN）的计算：
BSN is set to zero by SSID. First block will be sent with value zero. Value of BSN is increased by one for each data buffer to be transmitted. When BSN value exceeds 9, counter will be reset to zero.
BSN由SSID设置为零。第一个数据块将以零值发送。对于要传输的每个数据缓冲区，BSN的值增加1。当BSN值超过9时，计数器将重置为零。
Format: numeric/1 pos.
格式：数字/1位。
2. Calculation of the Block Checksum (BCS):
2. 块校验和（BCS）的计算：
Calculation is done as specified in the ISO DIS 8073 TRANSPORT LAYER document.
按照ISO DIS 8073传输层文件的规定进行计算。
Format: binary/2 pos.
格式：二进制/2位。
3. Shift-out transparency (See TRANSMIT/RECEIVE logic.)
3. 移出透明度（参见发送/接收逻辑。）
To avoid appearance of any control characters in the data stream, all the characters of the extended Exchange Buffer (with exception of the STX and carriage return characters enveloping the buffer) are put through a Shift-out logic, which result in a character being inserted (SO) and adding hex value '20' to the control character.
为了避免数据流中出现任何控制字符，扩展交换缓冲区的所有字符（包围缓冲区的STX和回车字符除外）都通过移位逻辑，这导致插入字符（SO）并向控制字符添加十六进制值“20”。
4. The carriage return is inserted at the end of the data buffer.
4. 回车插入到数据缓冲区的末尾。
Note: After adding STX, BSN, BCS, CR, and SO-logic, the data buffer may exceed the Data Exchange Buffer size.
注：添加STX、BSN、BCS、CR等逻辑后，数据缓冲区可能会超过数据交换缓冲区的大小。
These follow the ISO DIS 8073 TRANSPORT LAYER standard.
它们遵循ISO DIS 8073传输层标准。
SYMBOLS:
符号：
The following symbols are used:
使用以下符号：
C0,C1 Variables used in the algorithm L Length of the complete NSDU X Value of the first octet of the checksum parameter Y Value of the second octet of the checksum parameter
算法L中使用的C0、C1变量校验和参数第一个八位字节的完整NSDU X值的长度校验和参数第二个八位字节的Y值
ARITHMETIC CONVENTIONS:
算术约定：
Addition is performed in one of the two following modes:
通过以下两种模式之一执行添加：
a) modulo 255 arithmetic b) one's complement arithmetic in which if any of the variables has the value minus zero (i.e., 255) it shall be regarded as though if was plus zero (i.e., 0).
a) 模255算术b）一种补码算术，其中，如果任何变量的值为负零（即255），则应视为if为正零（即0）。
ALGORITHM FOR GENERATING CHECKSUM PARAMETERS:
生成校验和参数的算法：
. Set up the complete NSDU with the value of the checksum parameter field set to zero.
. 设置完整的NSDU，将校验和参数字段的值设置为零。
. Initialise C0 and C1 to zero.
. 将C0和C1初始化为零。
. Process each octet sequentially from i=1 to L by
. 按顺序从i=1到L处理每个八位组
a) adding the value of the octet to C0, then b) adding the value of C0 to C1.
a) 将八位字节的值与C0相加，然后b）将C0的值与C1相加。
. Calculate X and Y such that
. 计算X和Y，使
X = C0 - C1
Y = C1 - 2*C0
X = C0 - C1
Y = C1 - 2*C0
. Place the values X and Y in the checksum bytes 1 and 2, respectively.
. 将值X和Y分别放在校验和字节1和2中。
. Initialise parameters C0 and C1 to zero.
. 将参数C0和C1初始化为零。
. Process each octet of NSDU sequentially from i=1 to L by
. 按顺序从i=1到L处理NSDU的每个八位组
a) adding the value of the octet to C0, then b) adding the value of C0 to C1.
a) 将八位字节的值与C0相加，然后b）将C0的值与C1相加。
. If, when all the octets have been processed, either or both C0 and C1 does not have the value zero, then the checksum formulas have not been satisfied.
. 如果处理完所有八位字节后，C0和C1中的一个或两个值都不为零，则校验和公式不满足要求。
Note that the nature of the algorithm is such that it is not necessary to compare explicitly the stored checksum bytes.
请注意，该算法的本质是不需要显式比较存储的校验和字节。
(Transparency for all control characters)
（所有控制字符的透明度）
TRANSMIT LOGIC (values SO: X'0E' or X'8E')
传输逻辑（值SO:X'0E'或X'8E'）
Buffer(1), ... , (n) is a character in the buffer to be sent.
缓冲器（1），（n） 是缓冲区中要发送的字符。
FOR i=1 to n /* for all octets of the buffer */
FOR i=1 to n /* for all octets of the buffer */
IF ((buffer(i) & X'7F') < X'20')
IF ((buffer(i) & X'7F') < X'20')
THEN output (SO) output (buffer(i) + X'20')
然后输出（SO）输出（缓冲区（i）+X'20'）
ELSE output (buffer(i))
ELSE输出（缓冲区（i））
NEXT:
下一步：
RECEIVE LOGIC (values SO: X'0E' or X'8E')
接收逻辑（值SO:X'0E'或X'8E'）
Buffer(1), ... , (n) is a character in the received buffer.
缓冲器（1），（n） 是接收缓冲区中的字符。
drop = false
FOR i=1 to n /* for all octets of the buffer */
drop = false
FOR i=1 to n /* for all octets of the buffer */
IF drop = true
如果drop=true
THEN output (buffer(i) - X'20') drop = false
然后输出（缓冲区（i）-X'20'）drop=false
ELSE IF buffer(i) = (X'0D' or X'8D')
THEN Stop
ELSE IF buffer(i) = SO
THEN drop = true
ELSE output (buffer(i))
ELSE IF buffer(i) = (X'0D' or X'8D')
THEN Stop
ELSE IF buffer(i) = SO
THEN drop = true
ELSE output (buffer(i))
NEXT:
下一步：
Before an (ODETTE-FTP) asynchronous entity --> Modem --> PAD --> (ODETTE-FTP) native X.25 link can be established, the target PAD parameters must be set such that correct communication is established. It is strongly recommended that the PAD parameters are set by the X.25 entity. CCITT recommendations X.3, X.28, and X.29 define the PAD parameters and procedures for exchange of control information and user data between a PAD and a packet mode Data Terminal Equipment (DTE).
在建立（ODETTE-FTP）异步实体-->调制解调器-->PAD-->（ODETTE-FTP）本机X.25链路之前，必须设置目标PAD参数，以便建立正确的通信。强烈建议由X.25实体设置焊盘参数。CCITT建议X.3、X.28和X.29定义了PAD参数和程序，用于在PAD和分组模式数据终端设备（DTE）之间交换控制信息和用户数据。
Following is the Parameter list and values used to set the PAD for ODETTE-FTP communication. For further detailed information see the specification for CCITT X.25, X.28, X.29 and X.3.
以下是用于设置ODETTE-FTP通信PAD的参数列表和值。有关更多详细信息，请参阅CCITT X.25、X.28、X.29和X.3规范。
No. Description Value Meaning
---------------------------------------------------------------
1 Escape from Data Transfer 0 Controlled by host
2 Echo 0 No Echo
3 Data Forwarding Signal 2 Carriage Return
4 Selection of Idle Timer Delay 20 1 second
5 Ancillary Device Control 0 X-ON, X-OFF not used
6 PAD Service Signals 1 All except prompt
7 Procedure on Break 2 Reset
8 Discard Output 0 Do not discard
9 Padding after Carriage Return 0 No padding
No. Description Value Meaning
---------------------------------------------------------------
1 Escape from Data Transfer 0 Controlled by host
2 Echo 0 No Echo
3 Data Forwarding Signal 2 Carriage Return
4 Selection of Idle Timer Delay 20 1 second
5 Ancillary Device Control 0 X-ON, X-OFF not used
6 PAD Service Signals 1 All except prompt
7 Procedure on Break 2 Reset
8 Discard Output 0 Do not discard
9 Padding after Carriage Return 0 No padding
10 Line Folding 0 No line folding 11 Terminal Data Rate - Read only 12 Flow Control of the PAD 0 No flow control used 13 Linefeed Insertion after C/R 0 No linefeed 14 Linefeed Padding 0 No linefeed padding 15 Editing 0 No editing 16 Character Delete 127 Delete 17 Line Delete 24 <CTRL>X 18 Line Display 18 <CTRL>R 19 Editing PAD Service Signals 0 No service signal 20 Echo Mask 0 No echo mask 21 Parity Treatment 0 No parity check 22 Page Wait 0 No page wait
10行折叠0无行折叠11终端数据速率-只读12焊盘流量控制0无流量控制使用13 C/R后换行插入0无换行14换行填充0无换行填充15编辑0无编辑16字符删除127删除17行删除24<CTRL>x18行显示18<CTRL>R19编辑焊盘维修信号0无服务信号20回波掩码0无回波掩码21奇偶校验处理0无奇偶校验22页面等待0无页面等待
Note 1:
注1：
Refer to CCITT (1984) - Parameters 1 - 12 are mandatory and available internationally. - Parameters 13 - 22 may be available on certain networks and may also be available internationally. - A parameter value may be mandatory or optional.
参考CCITT（1984）-参数1-12是强制性的，在国际上可用。-参数13-22可能在某些网络上可用，也可能在国际上可用。-参数值可以是必需的，也可以是可选的。
The ODETTE profile refers only to parameter values which must be internationally implemented if the parameter is made available internationally.
ODETTE配置文件仅指参数值，如果参数在国际上可用，则必须在国际上实现这些参数值。
The ODETTE-FTP "special-logic" parameter may be impossible on some PADs because they do not support of some of the parameters (13 - 22). (If the PAD is supporting parity check (21) by default, ODETTE-FTP special logic would be impossible.)
ODETTE-FTP“特殊逻辑”参数在某些焊盘上可能不可用，因为它们不支持某些参数（13-22）。（如果PAD默认支持奇偶校验（21），则不可能使用ODETTE-FTP特殊逻辑。）
It is a user responsibility to ensure special logic consistency when making the PAD subscription.
用户有责任在进行PAD订阅时确保特殊逻辑的一致性。
Note 2:
注2：
Some parameters may have to be set differently depending on: - Make and function of the start-stop mode DTE entity. - Start-stop mode DTE entity ODETTE-FTP monitor function. - PAD services implemented. - Packet mode DTE entity ODETTE-FTP monitor function.
某些参数的设置可能会有所不同，具体取决于：-启动-停止模式DTE实体的品牌和功能。-启动-停止模式DTE实体ODETE-FTP监控功能。-已实现PAD服务。-数据包模式DTE实体ODETTE-FTP监控功能。
This appendix describes the recommendation of ODETTE Group 4 (1) for the use of OFTP (2) over X.25 over ISDN.
本附录描述了ODETTE第4（1）组关于通过ISDN在X.25上使用OFTP（2）的建议。
(1) ODETTE Group 4 is responsible for the specification of Telecommunications standards and recommendations for use within the Automotive Industry.
(1) ODETTE Group 4负责汽车行业内使用的电信标准和建议的规范。
(2) OFTP (ODETTE File Transfer Protocol) is the communications standard specified by ODETTE Group 4 designed for the transfer of both EDI and non-EDI data.
(2) OFTP（ODETE文件传输协议）是ODETE第4组规定的通信标准，设计用于传输EDI和非EDI数据。
This document offers an introductory overview of a technical subject. It is structured to contain the ODETTE recommendation, together with introductory information for the person not familiar with ISDN, and notes on the issues associated with the implementation of the recommendation.
本文档提供了一个技术主题的介绍性概述。它的结构包含ODETTE建议，以及为不熟悉ISDN的人提供的介绍性信息，以及关于与建议实施相关的问题的说明。
The first section provides the detailed ODETTE recommendation, which is followed by a general discussion. If you are not familiar with the terminology, please read the subsequent sections first.
第一节提供了详细的ODETTE建议，随后是一般性讨论。如果您不熟悉术语，请先阅读后面的章节。
How far an existing X.25 Line adapter may be replaced by an ISDN line adapter in an installation depends on the opportunities in view of connections (X.25 or ISDN) of the involved partners for file transfer.
在安装过程中，现有的X.25线路适配器在多大程度上可以被ISDN线路适配器替换，这取决于相关合作伙伴的文件传输连接（X.25或ISDN）的机会。
Companies that keep many connections to external partners (for example, car manufacturing companies) may use the OFTP file transfer in view of compatibility, which must always be considered anyway only in parallel to the X.25 network.
与外部合作伙伴保持大量连接的公司（例如，汽车制造公司）可能会使用OFTP文件传输，以确保兼容性，但无论如何，只有在与X.25网络并行的情况下才能考虑这种兼容性。
It is not the aim of this recommendation to remove the OFTP file transfer generally from the X.25 network to the ISDN network. This will not always be possible for international connections because of technical reasons, and this does not always make sense for connections with a low size of data to be transmitted.
本建议的目的并不是一般取消从X.25网络到ISDN网络的OFTP文件传输。由于技术原因，这对于国际连接并不总是可能的，对于传输数据量较小的连接来说，这并不总是有意义的。
Certainly, the use of ISDN, when exchanging a high volume of data (for example, CAD/CAM files), is very much cheaper than the use of an X.25 network. For such cases, this recommendation shall provide a cost-effective possibility for file transfer.
当然，在交换大量数据（例如CAD/CAM文件）时，使用ISDN比使用X.25网络便宜得多。对于这种情况，本建议应为文件传输提供成本效益高的可能性。
This appendix is organized as follows. D.1 defines the ODETTE recommendation in these terms, D.2 introduces the ISDN environment to the unfamiliar reader, D.3 describes the various methods of connecting to ISDN, and D.4 covers implementation issues.
本附录的组织结构如下。D.1在这些术语中定义了ODETTE建议，D.2向不熟悉的读者介绍了ISDN环境，D.3描述了连接到ISDN的各种方法，D.4涵盖了实施问题。
X.25: Level 2 ISO 7776 Protocol
X.25：2级ISO 7776协议
Level 3 ISO 8208 Protocol
3级ISO 8208协议
Packet Size 128
数据包大小128
Level 2 7 Window Size
2级7窗口大小
Level 3 7 Window Size
3级7窗口大小
First LCN 1
第一个LCN 1
Number of LCNs 1
LCN数量1
Facilities Window Size and Packet Size negotiation shall be supported by everybody. Call User Data should not be required.
设施窗口大小和数据包大小协商应得到所有人的支持。呼叫用户数据不应是必需的。
Calling NUA Optionally provided by the call initiator.
呼叫发起人可选地提供呼叫NUA。
Called NUA Should be set to a value where the last 'n' digits can be specified by the called party.
被叫NUA应设置为被叫方可以指定最后“n”位的值。
ISDN: Apart from requesting a 64K unrestricted digital call, no ISDN features shall be required.
ISDN：除了请求64K无限制数字呼叫外，不需要ISDN功能。
Timeout control: To avoid connections (B channels) within the circuit-switched ISDN network remaining active but unused for a long time, the adapter should include a timeout control.
超时控制：为了避免电路交换ISDN网络中的连接（B通道）保持活动但长时间未使用，适配器应包括超时控制。
An ISDN connection (B channel) should be released if no X.25 packets have been transmitted on this connection for a longer time. For flexibility a variable user definable timer should be incorporated into the adapter.
如果ISDN连接（B通道）上没有传输X.25数据包的时间更长，则应释放该连接。为了灵活性，适配器中应包含一个用户可定义的可变计时器。
In the event of a timeout situation the adapter has to release the ISDN connection and notify the local OFTP by the transmission of a clear packet.
在超时情况下，适配器必须释放ISDN连接，并通过传输清除数据包通知本地OFTP。
The pages that follow are informational and do not form part of this recommendation.
以下页面仅供参考，不构成本建议的一部分。
The use of digital encoding techniques over such high-quality, error-free backbone networks has allowed the PTTs to offer high bandwidths to the end user. The service is named ISDN (Integrated Services Digital Network).
在这种高质量、无差错的骨干网络上使用数字编码技术使得ptt能够向最终用户提供高带宽。该业务被命名为ISDN（综合业务数字网）。
The increasing need to transfer larger volumes of EDI data, in particular CAD/CAM drawings, has focused attention upon high-speed, low-cost communication. The traditional X.25 over a Packet Switched Data Network (PSDN) has been a good general purpose communications subsystem. Unfortunately, its cost and transfer speed make PSDN expensive for the new requirement.
越来越多地需要传输更大容量的EDI数据，特别是CAD/CAM图纸，这使得人们将注意力集中在高速、低成本的通信上。传统的分组交换数据网（PSDN）上的X.25是一个良好的通用通信子系统。不幸的是，它的成本和传输速度使得PSDN对于新的需求来说非常昂贵。
X.25 over the new ISDN provides both the transfer speed and cost benefits to satisfy the new requirements.
X.25在新的ISDN上提供传输速度和成本效益，以满足新的要求。
We include the following terminology because for us to make sense of ISDN and X.25, it is important that we use definitions precisely and avoid the abuses of the past.
我们使用以下术语是因为为了理解ISDN和X.25，准确使用定义并避免过去的滥用是很重要的。
ISDN: Integrated Services Digital Network
综合业务数字网
X.25: X.25 is a communications protocol. It defines the structure of data packets that comprise the protocol and the manner in which they are used.
X.25:X.25是一种通信协议。它定义了组成协议的数据包的结构及其使用方式。
PSDN: A PSDN (Packet Switched Data Network) is a network over which the X.25 protocol is operated.
PSDN:PSDN（分组交换数据网络）是一个X.25协议运行的网络。
PSPDN: A PSPDN (Packet Switched Public Data Network) is a PSDN operated by the PTTs. PSPDNs are given trade names, such as PSS in the UK, Datex-P in Germany, and Transpac in France.
PSPDN:PSPDN（分组交换公共数据网）是由PTT运营的PSDN。PSPDN被命名为商品名，如英国的PSS、德国的Datex-P和法国的Transpac。
BRI: Basic Rate Interface, also known as Basic Rate Access, defines an ISDN facility with 2 x 64 K B channels.
BRI：基本速率接口，也称为基本速率访问，定义了具有2 x 64 KB通道的ISDN设施。
PRI: Primary Rate Interface, also known as Primary Rate Access, defines an ISDN facility with 30 x 64 K B channels.
PRI:Primary Rate Interface，也称为Primary Rate Access，定义了具有30 x 64 KB通道的ISDN设施。
Channels: ISDN is typically brought into a consumer's premises using a twisted pair of wire. Over this wire, data can be transmitted in frequency bands. These frequency bands are allocated as channels.
信道：ISDN通常使用双绞线引入消费者的场所。通过这根电线，数据可以在频带内传输。这些频带被分配为信道。
B channels: The B channels are the data channels and operate at 64 Kb. The two end users of a connection will communicate over a B channel.
B通道：B通道是数据通道，以64 Kb运行。连接的两个最终用户将通过B通道进行通信。
D channel: Signalling on ISDN is performed over the D channel. Signalling is used to set up and release connections on the B channels. In some countries, the D channel can also be used for limited X.25 access to the PTTs' PSDN.
D通道：ISDN上的信令通过D通道执行。信令用于建立和释放B通道上的连接。在一些国家，D频道也可用于有限的X.25接入PTTs的PSDN。
The D channel operates at the lower speed of 16 Kb as it is normally used only at the beginning and end of a connection.
D通道以16 Kb的较低速度运行，因为它通常仅在连接的开始和结束时使用。
Bandwidth Allocation: 2 Wire B2 - 64 Kb Twisted Pair B1 - 64 Kb D Channel - 16 Kb
带宽分配：2线B2-64 Kb双绞线B1-64 Kb D通道-16 Kb
The standard for the operation of the D channel is called ETSI and is used in most European countries. However, some countries that started the introduction very early used proprietary standards, for example:
D通道的操作标准称为ETSI，在大多数欧洲国家使用。然而，一些很早就开始采用专利标准的国家，例如：
1TR6 - Used in Germany BTNR - Used in the UK
1TR6-用于德国BTNR-用于英国
Although there are D channel variations, this will not affect communications over the B channels as the communication over the D channel is between the subscriber and the ISDN service provider.
虽然存在D信道变化，但这不会影响B信道上的通信，因为D信道上的通信是在用户和ISDN服务提供商之间进行的。
However, the consumer's equipment must be able to handle the channel D signalling operated by the ISDN service provider and so there may be a problem of equipment availability and certification.
然而，用户的设备必须能够处理ISDN服务提供商操作的信道D信令，因此可能存在设备可用性和认证问题。
All the PTTs have committed to migrate to ETSI (also known as EURO-ISDN and Q.931) and many are currently supporting both their national variant and ETSI. It is advisable that in this situation the subscriber select the ETSI variant to avoid unnecessary equipment obsolescence.
所有PTT都已承诺迁移到ETSI（也称为EURO-ISDN和Q.931），许多PTT目前支持其国家变体和ETSI。在这种情况下，建议用户选择ETSI变体，以避免不必要的设备过时。
Services: The high-speed service is provided in two forms, Basic and Primary.
服务：高速服务以两种形式提供，基本和主要。
Basic: 2+D, the D 2B channel operates at 16 Kb. The Basic Rate access is normally provided to the subscriber over simple twisted pair cable.
基本：2+D，D2B通道以16 Kb运行。基本速率接入通常通过简单的双绞线电缆提供给用户。
Primary: 30B+D, the D channel operates at 64 Kb. Primary Rate access is normally provided to the subscriber over shielded coaxial cable. Note that the bandwidth for Primary is 2.048 Mbit/s.
主：30B+D，D通道以64KB运行。主要速率接入通常通过屏蔽同轴电缆提供给用户。请注意，主设备的带宽为2.048 Mbit/s。
Protocols: The B channel is a binary channel and is transparent to the flow of data. Therefore, all of the currently available protocols can operate over a B channel. The most common protocol is X.25.
协议：B通道是一个二进制通道，对数据流是透明的。因此，所有当前可用的协议都可以在B通道上运行。最常见的协议是X.25。
X.25: The X.25 protocol is a primary protocol for open computer-to-computer communication.
X.25:X.25协议是开放式计算机对计算机通信的主要协议。
Passive Bus: It is possible to have an ISDN service enter a building and then have an 8-core cable laid within the building with multiple ISDN junction points, in the same way as one would have multiple telephone points (extensions) for a particular external telephone line.
无源总线：可以让一个ISDN服务进入建筑物，然后在建筑物内铺设一条8芯电缆，带有多个ISDN连接点，就像一条特定的外部电话线有多个电话点（分机）一样。
Connection Setup
连接设置
The adapter is responsible for analysing the outgoing X.25 call request and making an ISDN call to a derived ISDN address, establishing a new X.25 level-2 and level-3, and then propagating the X.25 Call Request Packet.
适配器负责分析传出的X.25呼叫请求，并对派生的ISDN地址进行ISDN呼叫，建立新的X.25 2级和3级，然后传播X.25呼叫请求数据包。
Connection Termination
连接终止
The termination phase of the X.25 call is made with a Clear Request and finalised with a Clear Confirmation. The recipient of the Clear Confirm should then close down the ISDN connection.
X.25呼叫的终止阶段以明确的请求进行，并以明确的确认完成。然后，清除确认的接收者应关闭ISDN连接。
The clear down of the ISDN connection should only be made if there are no other Switched Virtual Circuits (SVCs) active on the ISDN connection; note that the usage of multiple simultaneous SVCs is only by virtue of bilateral agreement.
只有在ISDN连接上没有其他活动的交换虚拟电路（SVC）时，才应清除ISDN连接；请注意，多个同时SVC的使用仅取决于双边协议。
There are a number of ways in which ISDN/X.25 access can be made.
ISDN/X.25访问有多种方式。
Integrated Adapter
集成适配器
This is normally a PC-based ISDN adapter inside a PC. It is normal in such an environment that the OFTP application has the ability to manipulate the ISDN and X.25 aspects of the session independently and therefore have complete control.
这通常是PC内基于PC的ISDN适配器。在这样的环境中，OFTP应用程序能够独立操作会话的ISDN和X.25方面，因此具有完全控制权，这是正常的。
Equally important is that the speed of communication between the adapter and the application are at PC BUS speeds. It is therefore more likely that the effective transmission speed will be nearer the 64K limit.
同样重要的是，适配器和应用程序之间的通信速度为PC总线速度。因此，有效传输速度更可能接近64K限制。
The other benefit of such a direct linkage is that both 64K B channels may be used in parallel and both able to operate at 64Kb.
这种直接链接的另一个好处是，两个64K B通道可以并行使用，并且都能够以64Kb的速度运行。
Elementary Terminal Adapter
基本终端适配器
In this scenario, the computer has an integral X.25 adapter communicating X.21 with a Terminal Adapter that fronts the ISDN network. This allows a host with a X.25 capability to interface to ISDN, normally on a one-to-one basis.
在这种情况下，计算机有一个集成的X.25适配器，该适配器与面向ISDN网络的终端适配器通信X.21。这允许具有X.25功能的主机与ISDN接口，通常是一对一的方式。
The interface between the Terminal Adapter and the PC will typically only support one 64K B channel. This is obviously an inefficient usage of the ISDN service.
终端适配器和PC之间的接口通常只支持一个64K B通道。这显然是ISDN服务的低效使用。
Because the linkage between the computer and the Terminal Adapter is only X.25, then some modification/configuration may be needed inside the Terminal Adapter when new users are added.
由于计算机和终端适配器之间的链接仅为X.25，因此在添加新用户时，可能需要在终端适配器内部进行一些修改/配置。
X.25 Switch
X.25开关
This solution is normally found inside the larger corporates where an internal X.25 network is operated or where dual X.25 and ISDN is required.
这种解决方案通常存在于运行内部X.25网络或需要双X.25和ISDN的大型公司中。
The main benefit of a switch is to support both PSDN and ISDN simultaneously. Also, multiple X.21 lines may be implemented between the X.25 switch and the computer.
交换机的主要优点是同时支持PSDN和ISDN。此外，在X.25交换机和计算机之间可以实现多条X.21线路。
This solution normally requires more effort to configure and may require obligations to be placed upon how incoming callers specify routing.
此解决方案通常需要更多的工作来配置，并且可能需要对传入呼叫者如何指定路由设置义务。
The adoption of ISDN as an additional subsystem to support OFTP communications has associated implementation problems, which can be categorised as below:
采用ISDN作为支持OFTP通信的附加子系统存在相关的实施问题，可分为以下几类：
X.25/ISDN Addressing Making a Call Receiving a Call Logical Channel Assignment Facilities Negotiation ISDN Call Attributes Homologation Issues Growth Performance
X.25/ISDN寻址发出呼叫接收呼叫逻辑信道分配设施协商ISDN呼叫属性认证问题增长性能
The original OFTP was designed to work over the X.25 networks provided by the PTTs (PSPDNs). The national X.25 networks were interconnected to provide a global X.25 network, and a common addressing scheme was adopted by all. Although there were a few differences in addressing within a national network, the interface to other countries was quite rigid and normalised.
最初的OFTP设计用于在PTTs（PSPDNs）提供的X.25网络上工作。国家X.25网络相互连接，以提供一个全球X.25网络，所有国家都采用了共同的寻址方案。尽管在一个国家网络内处理问题存在一些差异，但与其他国家的接口相当僵化和规范化。
PSPDN Numbering
PSPDN编号
The addressing scheme adopted in X.25 is a 15-digit number (Network User Address, NUA) where the first three identify the country, the fourth digit identifies the network within the country, and the remainder specify the individual subscriber plus an optional subaddress. In the UK where a full X.25 numbering scheme is adopted, a NUA is, e.g., 234221200170, where 2342 is the DNIC (Data Network Identification Code) and 21200170 is the subscriber number.
X.25中采用的寻址方案是一个15位数字（网络用户地址，NUA），其中前三位标识国家，第四位标识国家内的网络，其余数字指定单个订户和可选子地址。在采用完整X.25编号方案的英国，NUA是，例如234221200170，其中2342是DNIC（数据网络标识码），21200170是订户号码。
ISDN Numbering
ISDN编号
ISDN is an extension of the normal telephone system; consequently, it adopts (or rather is) the same numbering scheme as the telephone system (PSTN).
ISDN是普通电话系统的延伸；因此，它采用（或者更确切地说是）与电话系统（PSTN）相同的编号方案。
The Numbering Conflict
编号冲突
The PSDN and PSTN numbering schemes are two totally different numbering schemes. There is no relationship between them. It is this conflict that is at the heart of the matter.
PSDN和PSTN编号方案是两种完全不同的编号方案。他们之间没有关系。这场冲突才是问题的核心。
It is a consequence of PSDN and PSTN being based upon different and unconnected numbering schemes that the key problem arises.
由于PSDN和PSTN基于不同且不相连的编号方案，因此出现了关键问题。
For X.25 to work over ISDN, three main methods of addressing are available:
对于在ISDN上工作的X.25，有三种主要的寻址方法：
Un-mapped: The X.25 called NUA is used as the PSTN number. Thus, an X.25 call to 0733394023 will result in a PSTN call to 0733394023 and the call request that consequently flows will also be to 0733394023.
未映射：称为NUA的X.25用作PSTN号码。因此，对0733394023的X.25呼叫将导致对0733394023的PSTN呼叫，并且随后流动的呼叫请求也将是对0733394023的。
Manipulated: The X.25 called NUA is manipulated by the subtraction and/or addition of digits to derive a resultant PSTN number. Thus, 2394023 could be manipulated to derive a PSTN number of 00944733394023, where the prefix 2 is deleted and replaced by 00944733.
操纵：称为NUA的X.25通过数字的减法和/或加法进行操纵，以得出结果PSTN号码。因此，可以操纵2394023来导出PSTN号码00944733394023，其中前缀2被删除并替换为00944733。
Mapped: The X.25 called NUA is used as a look-up into a table of PSTN numbers. Thus, an X.25 call to 234221200170 could be mapped to and result in a PSTN call to 0733394023 and the call request that consequently flows will remain as 234221200170.
映射：称为NUA的X.25用作PSTN号码表的查找。因此，对234221200170的X.25呼叫可以映射到并导致对0733394023的PSTN呼叫，并且因此流的呼叫请求将保持为234221200170。
Un-mapped Calls
未映射呼叫
Un-mapped calls are where the host-specified X.25 NUA is converted directly to the corresponding ISDN number.
未映射呼叫是指主机指定的X.25 NUA直接转换为相应的ISDN号码。
Thus, an X.25 call issued by the host to X.25 NUA 0733394023 will result in an ISDN call to the PSTN number 0733394023. After the call has been established, then HDLC/X.25 protocol setup will be established after which an X.25 call request will be transferred with the NUA 0733394023.
因此，主机向X.25 NUA 0733394023发出的X.25呼叫将导致向PSTN号码0733394023发出ISDN呼叫。建立呼叫后，将建立HDLC/X.25协议设置，之后将通过NUA 0733394023传输X.25呼叫请求。
When a PSTN call is made, the number of digits in the called number vary depending upon the location of the called party.
当进行PSTN呼叫时，被叫号码中的位数取决于被叫方的位置。
When a number is called, it may be local, national, or international.
当一个号码被呼叫时，它可能是本地的、国家的或国际的。
local: 394023 national: 0733 394023 international: 009 44 733 394023
本地：394023国家：0733 394023国际：009 44 733 394023
Depending upon where a call originates, the corresponding X.25 NUA in the call request packet will vary dramatically.
根据呼叫的起始位置，呼叫请求数据包中相应的X.25 NUA将发生显著变化。
Such variation of X.25 NUA, in particular the changing prefix, can be difficult to be accommodated by X.25 routing logic in many products.
在许多产品中，X.25路由逻辑很难适应X.25 NUA的这种变化，特别是前缀的变化。
When an international PSTN call is being made, then it is likely that the PSTN number exceeds 15 digits, which is the maximum length of an X.25 NUA. Therefore, using un-mapped addressing may make some international calls impossible to make.
当进行国际PSTN呼叫时，PSTN号码可能超过15位，这是X.25 NUA的最大长度。因此，使用未映射的寻址可能会使一些国际电话无法拨打。
Manipulated Calls
操纵呼叫
The X.25 called NUA is manipulated by the subtraction and/or addition of digits to derive a resultant PSTN number.
称为NUA的X.25通过数字的减法和/或加法操作，从而得出一个最终的PSTN号码。
Let us assume that by internal convention we have identified the prefix '2' to indicate an international ISDN call. Thus, an X.25 call request of 244733394023 could be manipulated to derive a PSTN number of 00944733394023, where the prefix '2' is deleted and replaced by '009' (the international prefix).
让我们假设，根据内部约定，我们已识别前缀“2”以表示国际ISDN呼叫。因此，可以操纵244733394023的X.25呼叫请求来导出00944733394023的PSTN号码，其中前缀“2”被删除并替换为“009”（国际前缀）。
The X.25 called NUA would typically be left in its un-manipulated state. As individual internal conventions vary, the X.25 called NUA will vary. In the case above, it would be 244733394023, but another installation might have the convention where a prefix of '56' specifies the UK and so the NUA will be 56733394023, where the '56' is deleted and replaced with '00944' to derive the PSTN number.
被称为NUA的X.25通常会处于未被操纵的状态。由于各个内部约定不同，称为NUA的X.25将有所不同。在上述情况下，它将是244733394023，但另一个安装可能有这样的约定，即前缀“56”指定英国，因此NUA将是56733394023，其中删除“56”并替换为“00944”以获得PSTN号码。
Mapped Calls
映射呼叫
The mapped method offers maximum flexibility in that:
映射方法在以下方面提供了最大的灵活性：
The PSTN number can exceed 15 digits.
PSTN号码可以超过15位。
The X.25 NUA and PSTN number can be totally different.
X.25 NUA和PSTN号码可能完全不同。
The problem with mapped calls is administrative. IBM mainframes can't handle X.25 over ISDN at all, let alone support mapping. For the mainframe solution to work, an external X.25/ISDN router box is required and it is the responsibility of the external box to provide any mapping necessary.
映射调用的问题是管理性的。IBM大型机根本无法通过ISDN处理X.25，更不用说支持映射了。为了使大型机解决方案正常工作，需要一个外部X.25/ISDN路由器盒，外部盒负责提供任何必要的映射。
This means that any changes or addition of OFTP partners over ISDN will require access to the computer room or special configuration equipment to change the tables inside the external X.25/ISDN router box.
这意味着，通过ISDN对OFTP合作伙伴进行的任何更改或添加都需要访问计算机室或特殊配置设备，以更改外部X.25/ISDN路由器盒内的表格。
We have seen from the previous section that the called X.25 NUA from an ISDN incoming call may vary considerably. If ISDN/X.25 is confined to a national boundary, then such variation will not be so great as most calls will have matching called X.25 NUA and PSTN numbers.
我们从上一节中看到，ISDN传入呼叫的被叫X.25 NUA可能会有很大差异。如果ISDN/X.25仅限于国家边界，那么这种变化将不会太大，因为大多数呼叫都有匹配的被叫X.25 NUA和PSTN号码。
X.25 switches and X.25 adapters normally route/accept/reject calls based upon their X.25 called NUA. In particular, routing is made upon the X.25 called NUA subaddress.
X.25交换机和X.25适配器通常根据其称为NUA的X.25路由/接受/拒绝呼叫。特别是，路由是在称为NUA子地址的X.25上进行的。
To derive this subaddress, there are 2 methods:
要派生此子地址，有两种方法：
1) the last 'n' digits are analysed.
1) 分析最后的“n”位。
2) the base X.25 NUA of the line is removed from the called NUA. For example, if the called X.25 NUA is 23422120017010 and the PSDN subscriber NUA is 234221200170, then the subaddress derived from subtraction is 10.
2) 线路的基准X.25 NUA从被称为NUA的线路中删除。例如，如果被调用的X.25 NUA是234221120017010，而PSDN订户NUA是2342211200170，则从减法中派生的子地址是10。
Obviously, the second method will not work if the incoming NUA varies.
显然，如果传入的NUA发生变化，第二种方法将不起作用。
ISDN Features
ISDN特性
ISDN, like X.25, has a core set of features that are then enriched with options. In the original OFTP X.25 specification, it was decided that the Q-bit and D-bit options were not common to all networks or applications; they were therefore positively excluded from the specification.
与X.25一样，ISDN也有一组核心功能，这些功能随后通过选项进行了丰富。在最初的OFTP X.25规范中，决定了Q位和D位选项并非所有网络或应用都通用；因此，他们被排除在规范之外。
It is proposed that apart from the core ISDN features necessary to establish a call, no other features be used.
建议除建立呼叫所需的核心ISDN功能外，不得使用其他功能。
Subaddressing
子寻址
There are two forms of ISDN subaddressing, overdialled and specific.
ISDN子地址有两种形式，过度指定和特定。
The overdial method allows an ISDN number to be artificially extended. A typical case would be where a private exchange has been installed in a larger company. Assume that the base number is 394023 and the computer is on internal extension 1234, then by specifying an ISDN number of 3940231234, direct access may be made to the internal extension.
过量法允许人工扩展ISDN号码。一个典型的例子是，大型公司安装了专用交换机。假设基本号码是394023，计算机位于内部分机1234上，则通过指定ISDN号码394023234，可以直接访问内部分机。
The problem with this method is that it extends to called number and may, especially for international access, exceed the ISDN numbering limits between countries.
这种方法的问题是，它扩展到被叫号码，并且可能超过国家间的ISDN号码限制，特别是对于国际接入。
The other method of subaddressing is where a discrete subaddress is placed in a specific field in the ISDN call setup.
子地址的另一种方法是，在ISDN呼叫设置中，将离散子地址放置在特定字段中。
The problem with this method, is that it requires the caller to place the subaddress in the ISDN call setup. Not all ISDN implementations will allow this insertion.
此方法的问题在于，它要求调用者在ISDN呼叫设置中放置子地址。并非所有ISDN实现都允许这种插入。
In conclusion, subaddressing of any kind should be avoided.
总之，应该避免任何类型的子寻址。
An X.25 dataline will have associated with it a number of logical channels.
X.25数据线将与多个逻辑通道相关联。
The number of channels is a part of the agreement between the PTT and the subscriber. The number of channels subscribed to is important; call failure and similar problems will result if the number of logical channels defined at the two remote ends are different.
频道数量是PTT和订户之间协议的一部分。订阅的频道数量很重要；如果在两个远程端定义的逻辑通道数量不同，将导致呼叫失败和类似问题。
If a DTE makes a call out, then the highest defined logical channel number will be selected. If the remote Data Communications Equipment (DCE) does not have the same number of logical channels defined, then an invalid logical channel is being used from the perspective of the recipient DCE and the call will be rejected.
如果DTE发出呼叫，则将选择定义的最高逻辑信道号。如果远程数据通信设备（DCE）没有定义相同数量的逻辑信道，则从接收方DCE的角度来看，正在使用无效的逻辑信道，呼叫将被拒绝。
In the PSPDN environment, it is possible to subscribe to negotiation of window size and packet size. Although this negotiation requested by the originator's DTE may be propagated to the remote DTE at the discretion of the originator's DCE, it is a local responsibility between the DTE and DCE pair.
在PSPDN环境中，可以订阅窗口大小和数据包大小的协商。尽管发端人的DTE请求的协商可以由发端人的DCE自行决定传播到远程DTE，但这是DTE和DCE对之间的本地责任。
In the ISDN scenario where it is a DTE-DTE type connection, the window size and packet size may be left at the default value and consequently the values may be omitted from the call request. If no values are specified, then it is vital that both DTEs have configured themselves to the recommended defaults.
在是DTE-DTE类型连接的ISDN场景中，窗口大小和分组大小可以保留在默认值，因此可以从呼叫请求中省略这些值。如果未指定任何值，则两个DTE必须将其自身配置为推荐的默认值。
The symptom of a window size mismatch is a hang situation without any informational error codes.
窗口大小不匹配的症状是没有任何信息性错误代码的挂起情况。
The symptoms of a packet size mismatch could work in some scenarios, but would otherwise issue error codes indicating invalid packet sizes.
数据包大小不匹配的症状在某些情况下可能会起作用，但在其他情况下会发出错误代码，指示数据包大小无效。
Window Size
窗口大小
The CCITT X.25 window size has a default value of '2', although subscribers may have other default window sizes, e.g., '7', by virtue of agreement with the PTT.
CCITT X.25窗口大小的默认值为“2”，尽管订阅者可能有其他默认窗口大小，例如，根据与PTT的协议为“7”。
Window size negotiation can be explicitly requested by specifying the requested window size in the Facilities fields in the Call Request packet.
通过在呼叫请求数据包的设施字段中指定请求的窗口大小，可以显式请求窗口大小协商。
Packet Size
数据包大小
The CCITT X.25 packet size has a default value of '128' octets, although subscribers may have other default values, e.g., '1024', agreed with the PTT.
CCITT X.25数据包大小的默认值为“128”个八位字节，尽管订户可能有其他默认值，例如与PTT商定的“1024”。
The initial setup of an ISDN call is initiated with the transmission of a Q.931 SETUP command. Apart from requesting that a call be established, the SETUP command can optionally carry information about the calling party, the called party, routing information, the type of circuit required (e.g., voice or data), and information about the protocols that are requested to be established.
ISDN呼叫的初始设置通过传输Q.931设置命令启动。除了请求建立呼叫之外，SETUP命令还可以选择性地携带关于呼叫方、被叫方、路由信息、所需电路类型（例如，语音或数据）的信息以及关于请求建立的协议的信息。
Setup Parameters:
设置参数：
Bearer capability Information transfer and access attributes
承载能力信息传输和访问属性
Called Party number Destination's network address
被叫方号码目的地的网络地址
Called Party subaddress Destination's complete address
被叫方子地址目标的完整地址
Calling Party number Source's network address
主叫方号码源的网络地址
Low-layer compatibility Layer 1-3 indication
低层兼容层1-3指示
High-layer compatibility Layer 4-7 indication
高层兼容层4-7指示
Homologation procedures were adopted and vigorously enforced by the PTTs with respect to the quality and conformance of communications equipment connected to the services provided by the PTTs.
PTT在与PTT提供的服务相关的通信设备的质量和合规性方面采用并严格执行了认证程序。
In particular, commercial X.25 products had to be tested and approved before they could be connected to the PTTs' PSPDN. The advantage of this to the subscriber was that there was very little chance of the approved equipment not working.
特别是，商用X.25产品在连接到PTTs的PSPDN之前必须经过测试和批准。这对用户的好处是，认可的设备不工作的可能性很小。
With ISDN, similar approval standards are still enforced. So the subscriber has the same confidence in their ISDN equipment. Wrong, the ISDN equipment itself is approved, but the X.15 protocol that operates on top of ISDN is now outside of the scope of approval services.
对于ISDN，类似的批准标准仍在执行。因此，用户对其ISDN设备具有相同的信心。错，ISDN设备本身已获得批准，但在ISDN之上运行的X.15协议现在不在批准服务范围内。
This means that quality of conformance to standards of X.25 over ISDN is subject to the variable quality procedures within the various ISDN equipment manufacturers.
这意味着在ISDN上符合X.25标准的质量取决于各个ISDN设备制造商内部的可变质量程序。
Although it is likely that commercial reputation will place pressure upon the manufacturers with a programming bug to correct such errors, it still requires the subscribers that do not communicate well to put time and effort into finding the party with the error.
尽管商业声誉可能会对有编程缺陷的制造商施加压力，要求他们纠正此类错误，但仍需要沟通不畅的订户投入时间和精力找到错误方。
So far, tests have shown a number of subtle errors, such as timing problems, that have taken many days to find, prove, and fix.
到目前为止，测试已经显示了一些微妙的错误，比如时间问题，这些错误需要很多天才能发现、证明和修复。
Primary Rate Access
主速率访问
If a user decides to plan for growth from the beginning, then the Primary Rate Access has apparent financial benefits. Such apparent savings are usually lost due to the increased cost of user hardware to support such an interface. The BRI for data usage is very common and cards/adapters are low in cost, whereas the PRI cards/adapters are few and far between and consequently highly priced.
如果一个用户决定从一开始就计划增长，那么主要的费率访问具有明显的经济效益。由于支持这种接口的用户硬件成本增加，这种明显的节约通常会损失。用于数据使用的BRI非常常见，卡/适配器的成本较低，而PRI卡/适配器的数量很少，因此价格较高。
Basic Rate Access
基本费率接入
One way to grow with ISDN is to buy multiple BRI lines, increasing slowly in units of 2 x B channels. The PTTs will be able to provide the same subscriber number for all the lines provided in a similar way to the traditional hunting group associated with PSTN type working.
ISDN增长的一个方法是购买多条BRI线路，以2 x B通道为单位缓慢增长。PTT将能够以类似于与PSTN类型工作相关联的传统搜索组的方式为所有线路提供相同的用户号码。
The obvious benefit of ISDN is speed; unfortunately, the majority of computer systems in use today have a finite amount of computing power available. The attachment of multiple active high-speed communication lines used in file transfer mode could take a significant amount of CPU resource to the detriment of other users on the system.
ISDN的明显优点是速度；不幸的是，目前使用的大多数计算机系统的可用计算能力有限。文件传输模式中使用的多条活动高速通信线路的连接可能占用大量CPU资源，对系统上的其他用户造成损害。
Connecting an ISDN line with the default 2 B channels to your computer using an X.21 interface is going to give a consistent 64 Kb throughput only if one of the B channels is active at any one time.
使用X.21接口将带有默认2个B通道的ISDN线路连接到您的计算机，仅当其中一个B通道在任何时间处于活动状态时，才能提供一致的64 Kb吞吐量。
If there are two 64 Kb channels active and contending for a single 64 Kb X.21 interface, then effective throughput will be reduced significantly to just over 50%.
如果有两个64 Kb通道处于活动状态，并争夺一个64 Kb X.21接口，则有效吞吐量将显著降低到略高于50%。
Mainframe issues:
大型机问题：
Users with a mainframe front-end are also going to find cost an issue. The scanners that scan the communications interfaces are based upon aggregate throughput. A 64 Kb interface takes up a lot of cycles.
拥有大型机前端的用户也会发现成本问题。扫描通信接口的扫描仪基于总吞吐量。64KB的接口占用大量的周期。
Determining 'DTE' or 'DCE' Characteristics
确定“DTE”或“DCE”特性
The following section is an extract from the ISO/IEC 8208 (International Standards Organization, International Electrotechnical Commission) (1990-03-15) standard, which is an ISO extension of the CCITT X.25 standard.
以下章节摘自ISO/IEC 8208（国际标准组织，国际电工委员会）（1990-03-15）标准，是CCITT X.25标准的ISO扩展。
The restart procedure can be used to determine whether the DTE acts as a DCE or maintains its role as a DTE with respect to the logical channel selection during Virtual Call establishment and resolution of Virtual Call collision.
重启过程可用于确定DTE在虚拟呼叫建立和解决虚拟呼叫冲突期间是否充当DCE或保持其作为DTE的角色。
When prepared to initialise the Packet Layer, the DTE shall initiate the restart procedure (i.e., transmit a RESTART REQUEST packet). The determination is based on the response received from the data exchange equipment (DXE) as outlined below.
当准备初始化数据包层时，DTE应启动重启程序（即，发送重启请求数据包）。该确定基于从数据交换设备（DXE）接收到的响应，如下所述。
a) If the DTE receives a RESTART INDICATION packet with a restarting cause code that is not 'DTE Originated' (i.e., it came from a DCE), then the DTE shall maintain its role as a DTE.
a) 如果DTE接收到一个重启指示数据包，其重启原因代码不是“源自DTE”（即来自DCE），则DTE应保持其作为DTE的角色。
b) If the DTE receives a RESTART INDICATION packet with a restarting cause code of 'DTE Originated' (i.e., it came from another DTE), then the DTE shall confirm the restart and act as a DCE.
b) 如果DTE收到重新启动指示数据包，其重新启动原因代码为“DTE起源”（即，它来自另一个DTE），则DTE应确认重新启动并充当DCE。
c) If the DTE receives a RESTART INDICATION packet with a restarting cause code of 'DTE Originated' (i.e., it came from another DTE) and it does not have an unconfirmed RESTART REQUEST packet outstanding (i.e., a restart collision), then the DTE shall consider this restart procedure completed but shall take no further action except to transmit another RESTART REQUEST packet after some randomly chosen time delay.
c) 如果DTE接收到重新启动指示数据包，其重新启动原因代码为“DTE起源”（即，它来自另一个DTE），并且它没有未确认的重新启动请求数据包（即，重新启动冲突），然后DTE将考虑此重启过程完成，但不采取进一步行动，除非在某些随机选择的时间延迟之后发送另一个重启请求分组。
d) If the DTE issues a RESTART REQUEST packet that is subsequently confirmed with a RESTART CONFIRMATION packet, then the DTE shall maintain its role as a DTE.
d) 如果DTE发出重新启动请求数据包，该数据包随后被重新启动确认数据包确认，则DTE应保持其作为DTE的角色。
Acknowledgements
致谢
This document draws extensively on revision 1.4 of the ODETTE File Transfer Specification [OFTP].
本文件广泛引用了ODETTE文件传输规范[OFTP]第1.4版。
Many people have contributed to the development of this protocol and their work is hereby acknowledged.
许多人为本议定书的制定做出了贡献，特此确认他们的工作。
Normative References
规范性引用文件
[CMS-Compression] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[CMS压缩]Gutmann，P.，“加密消息语法（CMS）的压缩数据内容类型”，RFC 3274，2002年6月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[ISO-646] International Organisation for Standardisation, ISO Standard 646:1991, "Information technology -- ISO 7-bit coded character set for information interchange", 1991.
[ISO-646]国际标准化组织，ISO标准646:1991，“信息技术——信息交换用ISO 7位编码字符集”，1991年。
[PKCS#1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[PKCS#1]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[UTF-8] Yergeau, F., "UTF-8, A Transformation Format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[ZLIB]Deutsch，P.和J-L.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
Informative References
资料性引用
[ISO-6523] International Organisation for Standardisation, ISO Standard 6523:1984, "Data interchange -- Structures for the identification of organisations", 1984.
[ISO-6523]国际标准化组织，ISO标准6523:1984，“数据交换——组织标识结构”，1984年。
[OFTP] Organisation for Data Exchange by Tele Transmission in Europe, Odette File Transfer Protocol, Revision 1.4, April 2000.
[OFTP]欧洲远程传输数据交换组织，Odette文件传输协议，第1.4版，2000年4月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP]Postel，J.和J.Reynolds，“文件传输协议”，STD 9，RFC 959，1985年10月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RIME] Coleridge, Samuel Taylor, "The Rime of the Ancient Mariner", 1817.
柯勒律治，塞缪尔·泰勒，“古代水手的雾凇”，1817年。
[X.509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[X.509]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[RFC3850]Ramsdell，B，“安全/多用途Internet邮件扩展（S/MIME）版本3.1证书处理”，RFC 38502004年7月。
ODETTE Address
奥德特地址
The ODETTE File Transfer Protocol is a product of the Technology Committee of Odette International. The Technology Committee can be contacted via the ODETTE Central Office:
ODETTE文件传输协议是ODETTE International技术委员会的产品。可通过奥德特中心办公室联系技术委员会：
ODETTE INTERNATIONAL Limited Forbes House Halkin Street London SW1X 7DS United Kingdom
奥德特国际有限公司福布斯豪斯哈尔金街伦敦SW1X 7DS英国
Phone: +44 (0)171 344 9227
Fax: +44 (0)171 235 7112
EMail: info@odette.org
URL: http://www.odette.org
Phone: +44 (0)171 344 9227
Fax: +44 (0)171 235 7112
EMail: info@odette.org
URL: http://www.odette.org
Author's Address
作者地址
Ieuan Friend Data Interchange Plc Rhys House The Minerva Business Park Lynchwood Peterborough PE2 6FT United Kingdom
Ieuan Friend数据交换有限公司里斯之家密涅瓦商业园林奇伍德彼得堡PE2 6英尺英国
Phone: +44 (0)1733 371 311
EMail: ieuan.friend@dip.co.uk
Phone: +44 (0)1733 371 311
EMail: ieuan.friend@dip.co.uk
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.