Standard number: JR/T 0182-2020
Standard name: Lightweight real-time STEP message transfer protocol
English name: Light weight realtime STEP message transfer protocol ||
tt||Standard format: PDF
Release time: 2020-02-26
Implementation time: 2020-02-26
Standard size: 489K
Standard introduction: This standard specifies the session mechanism, message format, security and encryption, data integrity, extension method, message format specification, data dictionary, etc. used by the Lightweight Real-time STEP Message Transfer Protocol (Light-weight realtime STEP message transfer protocol).
This standard JR/T 0182-2020 is applicable to support the exchange of business data between stock exchanges and market participants and related financial institutions.
This standard can also be promoted to support session connections between systems of various institutions in the securities and futures industry.
This standard is drafted in accordance with the rules given in GB/T1.1-2009
This standard is proposed by the Securities Technical Committee of the National Financial Standardization Technical Committee (SAC/TC180/SC4)
This standard is under the jurisdiction of the National Financial Standardization Technical Committee (SAC/TC180) The drafting units of this standard are: Information Center of China Securities Regulatory Commission, Shanghai Stock Exchange, Shenzhen Stock Exchange, China Securities Information Technology Services Co., Ltd.
Main drafters of this standard: Yao Qian, Liu Tiebin, Zhou Yunhui, Du Juan, Zhu Li, Wang Pengfei, Li Xiangdong
This standard specifies the session mechanism, message format, security and encryption, data integrity, extension method, message format specification, data dictionary, etc. used by the Light-weight realtime STEP message transfer protocol. This standard is applicable to support the exchange of business data between stock exchanges and market participants and related financial institutions. This standard can also be promoted to support session connections between systems of various institutions in the securities and futures industry.
This standard was drafted in accordance with the rules given in GB/T 1.1-2009.
This standard was proposed by the Securities Technical Committee of the National Financial Standardization Technical Committee (SAC/TC180/SC4).
This standard is under the jurisdiction of the National Financial Standardization Technical Committee (SAC/TC180).
This standard was drafted by the Information Center of the China Securities Regulatory Commission, Shanghai Stock Exchange, Shenzhen Stock Exchange, and China Securities Information Technology Services Co., Ltd.
The main drafters of this standard are Yao Qian, Liu Tiebin, Zhou Yunhui, Du Juan, Zhu Li, Wang Pengfei, and Li Xiangdong.
The following documents are indispensable for the application of this document. For any dated referenced document, only the version with the date is applicable to this document. For any undated referenced document, the latest version (including all amendments) is applicable to this document.
JR/T 0022—2014 Securities transaction data exchange protocol
ISO 10383:2012 Securities and related financial instruments-Codes for exchanges and market identification(MIC)
Financial information exchange protocol(FIX) Version 5.0 Service Pack 2,August 2011
Financial information exchange protocol(FIX) FIX session protocol version1.1,March 2008
Foreword II
Introduction III
1 Scope1
2 Normative references1
3 Terms and definitions1
4 Session mechanism1
41 Important notes on key concepts1
42 Session management5
43 Recovery6
5 Message Specifications6
51 Message Structure7
52 Management Messages8
6 Data Dictionary14
61 Data Types14
62 Session Layer Domain Specifications15
Appendix A (Normative Appendix) Calculating Checksums17
Appendix B (Normative Appendix) Handling Heartbeat and Test Requests18
Appendix C (Normative Appendix) Login Scenarios19
C1 Normal Login Scenario 119
C2 Normal Login Scenario 220
C3 Normal Login Scenario 320
C4 Abnormal Login Scenario 122
C5 Abnormal Login Scenario 222
Appendix D (Normative Appendix) Handling Session Rejection24
Appendix E (Normative Appendix) Processing Retransmission Request Scenario 25
E1 Processing Retransmission Request Scenario 1 25
E2 Processing Retransmission Request Scenario 2 26
Appendix F (Normative Appendix) Deregistration Scenario 27

ICS03.060
iiiKAa~cJouakAa
Financial Industry Standard of the People's Republic of China
JR/T0182—2020
Light weight realtime STEP message transfer protocol
Light weight realtime STEP message transfer protoco2020-02-26 Release
China Securities Regulatory Commission
2020-02-26 Implementation
iiiKAa~cJouaKAa
Introduction,
Normative references
3 Terms and definitions
4 Session mechanism
iiikAacJouakAa-
Important notes on key concepts
Session management,
5 Message specification
Message structure.
Management message
6 Data dictionary
Appendix A
Appendix B
Appendix C
Appendix D
Appendix E
Appendix F
Data types
Session layer domain Specification.
(Normative Appendix) Calculate checksum
(Normative Appendix) Process heartbeat and test requests.(Normative Appendix) Login scenario
Normal login scenario
Normal login scenario
Normal login scenario
Abnormal login scenario
Abnormal login scenario
(Normative Appendix) Handle session rejection
(Normative Appendix) Handle retransmission request scenario Handle retransmission request scenario
Handle retransmission request scenario
(Normative Appendix) Logout scenario
JR/T0182—2020
JR/T0182—2020
iiiKAa~cJouakAa
This standard was drafted according to the rules given in GB/T1.1-2009. This standard is proposed by the Securities Technical Committee of the National Financial Standardization Technical Committee (SAC/TC180/SC4). This standard is under the jurisdiction of the National Financial Standardization Technical Committee (SAC/TC180). The drafting units of this standard are: Information Center of China Securities Regulatory Commission, Shanghai Stock Exchange, Shenzhen Stock Exchange, and China Securities Information Technology Services Co., Ltd.
The main drafters of this standard are: Yao Qian, Liu Tiebin, Zhou Yunhui, Du Juan, Zhu Li, Wang Pengfei, and Li Xiangdong. 11
iiiKAa~cJouakAa
JR/T0182—2020
FIX (Financial Information eXchange) protocol is the financial information exchange protocol, which is a protocol for electronic financial information exchange between global financial market institutions and participants, hereinafter referred to as the FIX protocol. In the FIX5.0 standard proposed by the FIX Standardization Organization (FIXTradingCommunity), a session layer protocol (FIXSessionProtocol, FIXT) is defined separately, and its version is FIXT1.1. JR/T0022-2014 Securities Trading Exchange Protocol (STEP) is the industry standard for the FIX protocol. This standard is a lightweight version of the session layer protocol in FIXT1.1 and JR/T0022-2014. iiiKAa~cJouaKAa
1Scope
iiiKAa~cJouaKAa-
Lightweight real-time STEP message transfer protocol
JR/T0182—2020
This standard specifies the session mechanism, message format, security and encryption, data integrity, extension method, message format specification, data dictionary, etc. used by the Light-weight real-time STEP message transfer protocol (Light-weight real-time STEP message transfer protocol).
This standard is applicable to support the exchange of business data between stock exchanges and market participants and related financial institutions. This standard can also be promoted to support the session connection between the systems of various institutions in the securities and futures industry. Normative reference documents
The following documents are indispensable for the application of this document. For all reference documents with dates, only the versions with the dates are applicable to this document. For all reference documents without dates, the latest versions (including all amendments) are applicable to this document. JR/T0022—2014
IS010383:2012
financial
Securities Transaction Data Exchange Protocol
Securities and related
instruments-Codes for exchanges and market identification (Mic))Financial
August 2011
Financial
March 2008
3 Terms and Definitions
information
information
exchange
protocol (FIx)
Version
5.0Service
exchangeprotocol (FIx) FIX
The following terms and definitions apply to this document.
Securities trading data exchange protocolwww.bzxz.net
session protocol
versionl.1
securtieatradingexchangeprotocol;STEpindustry information standard for the exchange of securities trading data between the stock exchange trading system and the market participants. 3.2
Financial information exchange protocol
financialinformationexchangeFixInternational information standard for the electronic exchange of securities trading information. 3.3
FIX session layer protocol
fix sessionlayerprotocol;FixTAn electronic data protocol that is independent of communication protocols (such as TCP, UDP, etc.) and communication media (such as optical cables, satellites, etc.), an important sub-protocol of the FIX protocol.
4 Session Mechanism
4.1 Important Explanation of Key Concepts
JR/T0182—2020
4.1.1 Session Layer Retransmission
iiiKAa~cJouakAa
4.1.1.1 This standard provides the session layer connection standard between the internal system of market participants and the stock exchange through an open interface. This standard is a simplified version of the FIXT1.1 standard of the FIX Standardization Organization, and the use of message tags follows the provisions of FIX5.0SP2. Since JR/T0022-2014 Securities Trading Data Exchange Protocol is only a localized version of the FIX protocol, in order to highlight the direct source of the standard, this standard is hereinafter referred to as "LFIXT".
4.1.1.2 Unless otherwise specified, the communication participants such as the receiver and sender mentioned in this standard specifically refer to the application or module implemented in accordance with this standard, hereinafter referred to as "LFIXT participants". Programs or modules developed based on FIXT (hereinafter referred to as "FIXT participants"), if they want to communicate with LFIXT participants, must also comply with the constraints of this standard. 4.1.1.3Session layer retransmission is a retransmission mechanism specified by the session layer protocol to ensure that each session layer message is transmitted in order and without loss. In the FXT session layer protocol, session layer retransmission is initiated by the message receiver when it identifies a message sequence number gap, by sending a message retransmission request to the other party. This standard actually cancels the session layer retransmission of the FIXT session layer protocol, and only appears as a standard FIXT session layer to the outside world, and can interoperate with the FIXT participants on the other end. Since a single LFIXT session uses a single TCP connection as the underlying communication mechanism, each message will be transmitted in order and without loss within a single TCP connection. Although there may be session layer message loss between successive TCP connections belonging to the same session, the received session layer messages will still have the nature of orderly reception. Since there may be message loss at the session layer under the LFIXT standard, the lost business messages can only be recovered through application layer retransmission.
4.1.1.4 Like the FIXT protocol, the LFIXT protocol itself does not limit the standard port number used. As a session layer protocol based on TCP, the port number used by LFIXT is recommended to be in the range [1024, 49151]. The specific value shall be agreed upon by the communicating parties in advance. 4.1.2 Application layer retransmission
Since the session layer recovery mechanism of this standard is only for compatibility with the FIXT session protocol, it cannot be used as a real message recovery mechanism. Therefore, it should be recovered through the retransmission mechanism agreed upon by the application layer. The specific mechanism of application layer retransmission does not fall within the scope of this standard. 4.1.3NxtIn and NxtOut
Each message sent and received by both parties of the session carries a message sequence number. Each end participating in the communication needs to maintain a pair of sequence numbers (NxtIn, NxtOut), NxtIn represents the next incoming message sequence number, and NxtOut represents the sequence number to be assigned to the next outgoing message. 4.1.4 Session initiator and receiver
4.1.4.1 The establishment of a session requires an initiator and a receiver. The initiator is the party that sends a Logon message first and hopes that the other party will respond with a Logon message. The acceptor is the party that waits for the initiator to send an I.ogon message first and responds with a Logon message. After the session is established, the initiator and acceptor of the session can send and receive information in both directions. Do not confuse the session initiator (initiator) and the session acceptor (acceptor) with the sender (ender) and receiver (receiver) of a specific message.
4.1.4.2 Similar to the session initiator and session acceptor, the concepts of logout initiator and logout acceptor, session reset initiator and session reset acceptor are also defined.
4.1.4.3The FIXT protocol is applicable to various transport layer protocols (such as UDP). Therefore, it is impossible to distinguish which messages belong to the same FIXT session based on specific transport layer information such as TCP socket. In addition, since FIXT does not define a so-called "session number" label for each FIXT session, and not all messages have labels such as username, the unique identifier that distinguishes FIXT sessions is the combination of the SenderCompID and TargetCompID fields. The LFIXT standard, as a simplified version of the FIXT standard, also follows this requirement. 2
iiiKAa~cJouaKAa
JR/T0182—2020
4.1.4.4In the FIXT protocol, a single FIXT participant cannot simultaneously maintain two sessions with the same SenderCompID+TargetCompID. The recommended practice in FIT is: when a valid session already exists, if one party attempts to initiate a new session with the same SenderCompID+TargetCompID, the other party will terminate the newly initiated session directly without sending any Logout message. The existing session should not be affected. On the other hand, the FIXT protocol does not specify whether different FIXT participants are allowed to maintain sessions with the same identifier at the same time. Generally speaking, it is easier to check for duplicates for sessions with the same identifier on the same server, while it is more difficult to check for duplicates for sessions with the same identifier established for different servers, but it is not impossible. When processing incoming login messages, SenderCompID and TargetCompID should be used to check for duplicates of sessions. Existing sessions with the same identifier will definitely not be affected, but later received requests for sessions with the same identifier may be accepted or rejected, which is not limited by the FIXT protocol. If the request is rejected, the rejection method will follow the agreement of the FIXT protocol, and the Logout message will not be sent back, and the TCP connection will be directly disconnected. The session initiator should be prepared for this situation. The LFIXT standard, as a simplified version of the FIXT standard, also follows this requirement. 4.1.4.5 This standard only allows a single session to communicate in full duplex through a single TCP connection at the same time. Therefore, after determining whether to allow continued communication through the login message information, the socket can be used directly to distinguish the session to which the message belongs. However, for subsequent messages received from the same socket, the SenderCompID and TargetCompID should still be checked to see if they are consistent with those at the time of login. 4.1.5 Message sequence number
All messages are identified by a unique session layer message sequence number (i.e., the MsgSeqNum field in the message header). The message sequence number is initialized to 1 at the beginning of the session in most cases, and increases continuously throughout the session until the session is completely terminated. By monitoring the continuity of the message sequence number, the communicating parties can identify message gaps and respond, and can synchronize between multiple connections before and after the same session.
The above "continuous increase" is for normal situations. In the following cases, the MsgSeqNum of the message received by the receiver may also flow backwards, but the flow backwards at this time is not abnormal, but is called "normal flow backwards": a) The received message is a SeqReset-Reset message and PossDupFlag=Y. In this case, MsgSeqNum should be ignored. Even if flow backwards occurs, it is not an error:
The PossDupFlag of the received message is Y, and this type of message does allow PossDupFlag=Y, indicating that this is a session layer reset b)
c) When the session sequence number is reset through the Logon message, the MsgSeqNum of the received message must be 1, so flow backwards may also occur.
Each session creates a set of independent inbound and outbound sequence numbers. Any party involved in the connection maintains a set of sequence numbers for outbound messages (NxtOut), and also maintains another independent sequence number sequence for inbound messages (NxtIn) to monitor the received message sequence numbers to ensure the discovery and processing of message gaps. After the session is established, when the LFIXT protocol implementer receives a message with a sequence number that is not equal to the expected message sequence number (NxtIn), it needs to consider correcting the process. There are several cases: a) If the incoming message sequence number isogon message and respond with Logon message. The initiator and the acceptor of a session can send and receive information in both directions after the session is established. Do not confuse the initiator and the acceptor of a session with the sender and the receiver of a specific message.
4.1.4.2 Similar to the initiator and the acceptor of a session, the concepts of logout initiator and logout receiver, session reset initiator and session reset receiver are also defined.
4.1.4.3 The FIXT protocol is applicable to various transport layer protocols (such as UDP), so it is impossible to distinguish which messages belong to the same FIXT session based on specific transport layer information such as TCP socket. In addition, since FIXT does not define a so-called "session number" label for each FIXT session, and not all messages have labels such as username, the unique identifier to distinguish FIXT sessions is the combination of the SenderCompID and TargetCompID fields. As a simplified version of the FIXT standard, the LFIXT standard also follows this requirement. 2
iiiKAa~cJouaKAa
JR/T0182—2020
4.1.4.4 In the FIXT protocol, a single FIXT participant cannot simultaneously maintain two sessions with the same SenderCompID+TargetCompID. The recommended practice in FIT is: when a legitimate session already exists, if one party attempts to initiate a new session with the same SenderCompID+TargetCompID, the other party will directly terminate the newly initiated session without sending any Logout message, and the existing session should not be affected. On the other hand, the FIXT protocol does not specify whether different FIXT participants are allowed to maintain sessions with the same identifier at the same time. Generally speaking, sessions with the same identifier on the same server are easier to check for duplicates, while sessions with the same identifier established for different servers are more difficult to check for duplicates, but it is not impossible. When processing incoming login messages, SenderCompID and TargetCompID should be used to check for duplicate sessions. Existing sessions with the same ID will not be affected, but later received requests for sessions with the same ID may be accepted or rejected, which is not limited by the FIXT protocol. If the request is rejected, the rejection method will follow the FIXT protocol agreement, and the Logout message will not be sent back, and the TCP connection will be directly disconnected. The session initiator should be prepared for this situation. The LFIXT standard, as a simplified version of the FIXT standard, also follows this requirement. 4.1.4.5 This standard only allows a single session to communicate in full-duplex through a single TCP connection at the same time. Therefore, after determining whether to continue communication through the login message information, the socket can be directly used to distinguish the session to which the message belongs, but for subsequent messages received from the same socket, the SenderCompID and TargetCompID should still be checked to see if they are consistent with those at the login time. 4.1.5 Message sequence number
All messages are identified by a unique session layer message sequence number (i.e., the MsgSeqNum field in the message header). In most cases, the message sequence number is initialized to 1 at the beginning of a session and increases continuously throughout the session until the session ends. By monitoring the continuity of the message sequence number, the communicating parties can identify message gaps and respond, and can synchronize multiple connections before and after the same session.
The above "continuous increase" is for normal situations. In the following cases, the MsgSeqNum of the message received by the receiver may also flow backwards, but the flow backwards at this time is not abnormal, but is called "normal flow backwards": a) The received message is a SeqReset-Reset message and PossDupFlag=Y. At this time, MsgSeqNum should be ignored, and even if flow backwards occurs, it is not an error:
The PossDupFlag of the received message is Y, and such messages do allow PossDupFlag=Y, indicating that this is a session layer reset b)
c) When the session sequence number is reset through the Logon message, the MsgSeqNum of the received message must be 1, so flow backwards may also occur.
Each session creates an independent set of inbound and outbound sequence numbers. Each party involved in the connection maintains a sequence number for outbound messages (NxtOut) and another independent sequence number for inbound messages (NxtIn) to monitor received message sequence numbers to ensure the discovery and processing of message gaps. After the session is established, when the LFIXT protocol implementer receives a message sequence number that is not equal to the expected message sequence number (NxtIn), it needs to consider correcting the process. There are several situations: a) If the inbound message sequence number isogon message and respond with Logon message. The initiator and the acceptor of a session can send and receive information in both directions after the session is established. Do not confuse the initiator and the acceptor of a session with the sender and the receiver of a specific message.
4.1.4.2 Similar to the initiator and the acceptor of a session, the concepts of logout initiator and logout receiver, session reset initiator and session reset receiver are also defined.
4.1.4.3 The FIXT protocol is applicable to various transport layer protocols (such as UDP), so it is impossible to distinguish which messages belong to the same FIXT session based on specific transport layer information such as TCP socket. In addition, since FIXT does not define a so-called "session number" label for each FIXT session, and not all messages have labels such as username, the unique identifier to distinguish FIXT sessions is the combination of the SenderCompID and TargetCompID fields. As a simplified version of the FIXT standard, the LFIXT standard also follows this requirement. 2
iiiKAa~cJouaKAa
JR/T0182—2020
4.1.4.4 In the FIXT protocol, a single FIXT participant cannot simultaneously maintain two sessions with the same SenderCompID+TargetCompID. The recommended practice in FIT is: when a legitimate session already exists, if one party attempts to initiate a new session with the same SenderCompID+TargetCompID, the other party will directly terminate the newly initiated session without sending any Logout message, and the existing session should not be affected. On the other hand, the FIXT protocol does not specify whether different FIXT participants are allowed to maintain sessions with the same identifier at the same time. Generally speaking, sessions with the same identifier on the same server are easier to check for duplicates, while sessions with the same identifier established for different servers are more difficult to check for duplicates, but it is not impossible. When processing incoming login messages, SenderCompID and TargetCompID should be used to check for duplicate sessions. Existing sessions with the same ID will not be affected, but later received requests for sessions with the same ID may be accepted or rejected, which is not limited by the FIXT protocol. If the request is rejected, the rejection method will follow the FIXT protocol agreement, and the Logout message will not be sent back, and the TCP connection will be directly disconnected. The session initiator should be prepared for this situation. The LFIXT standard, as a simplified version of the FIXT standard, also follows this requirement. 4.1.4.5 This standard only allows a single session to communicate in full-duplex through a single TCP connection at the same time. Therefore, after determining whether to continue communication through the login message information, the socket can be directly used to distinguish the session to which the message belongs, but for subsequent messages received from the same socket, the SenderCompID and TargetCompID should still be checked to see if they are consistent with those at the login time. 4.1.5 Message sequence number
All messages are identified by a unique session layer message sequence number (i.e., the MsgSeqNum field in the message header). In most cases, the message sequence number is initialized to 1 at the beginning of a session and increases continuously throughout the session until the session ends. By monitoring the continuity of the message sequence number, the communicating parties can identify message gaps and respond, and can synchronize multiple connections before and after the same session.
The above "continuous increase" is for normal situations. In the following cases, the MsgSeqNum of the message received by the receiver may also flow backwards, but the flow backwards at this time is not abnormal, but is called "normal flow backwards": a) The received message is a SeqReset-Reset message and PossDupFlag=Y. At this time, MsgSeqNum should be ignored, and even if flow backwards occurs, it is not an error:
The PossDupFlag of the received message is Y, and such messages do allow PossDupFlag=Y, indicating that this is a session layer reset b)
c) When the session sequence number is reset through the Logon message, the MsgSeqNum of the received message must be 1, so flow backwards may also occur.
Each session creates an independent set of inbound and outbound sequence numbers. Each party involved in the connection maintains a sequence number for outbound messages (NxtOut) and another independent sequence number for inbound messages (NxtIn) to monitor received message sequence numbers to ensure the discovery and processing of message gaps. After the session is established, when the LFIXT protocol implementer receives a message sequence number that is not equal to the expected message sequence number (NxtIn), it needs to consider correcting the process. There are several situations: a) If the inbound message sequence number is5 Message Sequence Number
All messages are identified by a unique session layer message sequence number (i.e., the MsgSeqNum field in the message header). The message sequence number is initialized to 1 in most cases at the beginning of a session and increases continuously throughout the session until the session ends. By monitoring the continuity of the message sequence number, the communicating parties can identify message gaps and respond, and can synchronize multiple connections before and after the same session.
The above "continuous increase" is for normal situations. In the following cases, the MsgSeqNum of the message received by the receiver may also flow backwards, but the flow backwards at this time is not abnormal, but is called "normal flow backwards": a) The received message is a SeqReset-Reset message and PossDupFlag=Y. In this case, MsgSeqNum should be ignored. Even if flow backwards occurs, it is not an error:
The PossDupFlag of the received message is Y, and this type of message does allow PossDupFlag=Y, indicating that this is a session layer reset b)
c) When the session sequence number is reset through the Logon message, the MsgSeqNum of the received message must be 1, so flow backwards may also occur.
Each session creates a set of independent inbound and outbound sequence numbers. Any party involved in the connection maintains a set of sequence numbers for outbound messages (NxtOut), and also maintains another independent sequence number sequence for inbound messages (NxtIn) to monitor the received message sequence numbers to ensure the discovery and processing of message gaps. After the session is established, when the LFIXT protocol implementer receives a message with a sequence number that is not equal to the expected message sequence number (NxtIn), it needs to consider correcting the process. There are several cases: a) If the incoming message sequence number is5 Message Sequence Number
All messages are identified by a unique session layer message sequence number (i.e., the MsgSeqNum field in the message header). The message sequence number is initialized to 1 in most cases at the beginning of a session and increases continuously throughout the session until the session ends. By monitoring the continuity of the message sequence number, the communicating parties can identify message gaps and respond, and can synchronize multiple connections before and after the same session.
The above "continuous increase" is for normal situations. In the following cases, the MsgSeqNum of the message received by the receiver may also flow backwards, but the flow backwards at this time is not abnormal, but is called "normal flow backwards": a) The received message is a SeqReset-Reset message and PossDupFlag=Y. In this case, MsgSeqNum should be ignored. Even if flow backwards occurs, it is not an error:
The PossDupFlag of the received message is Y, and this type of message does allow PossDupFlag=Y, indicating that this is a session layer reset b)
c) When the session sequence number is reset through the Logon message, the MsgSeqNum of the received message must be 1, so flow backwards may also occur.
Each session creates a set of independent inbound and outbound sequence numbers. Any party involved in the connection maintains a set of sequence numbers for outbound messages (NxtOut), and also maintains another independent sequence number sequence for inbound messages (NxtIn) to monitor the received message sequence numbers to ensure the discovery and processing of message gaps. After the session is established, when the LFIXT protocol implementer receives a message with a sequence number that is not equal to the expected message sequence number (NxtIn), it needs to consider correcting the process. There are several cases: a) If the incoming message sequence number is
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.