BME Data Feed Interface Specifications. Version: Related to: BME Data Feed Release 13.0

Size: px
Start display at page:

Download "BME Data Feed Interface Specifications. Version: Related to: BME Data Feed Release 13.0"

Transcription

1 1.1 BME Data Feed s Document Name: BME Data Feed s Version: 3.00 Related to: BME Data Feed Release 13.0 Last Updated

2 BME Data Feed s Page 2 of 2 REVISION HISTORY This section refers to the major changes of this version in comparison to the previous version. Version Date Comments First cut Several updated special requests in whole document additional value for Open Outcry in App. G+H Changed FID for field NEWS_ID. Graphics and text correction. Correction on section 5.15 Message - Remove Watch by Product Request. Revised Appendixes G and H Introduction of extended time resolution principles. Ch 3.7 Changed format and additional processing of MICRO and NANO seconds time stamps. Higher time resolution information. Ch. 5.1, 5.2, 5.6, 5.9, 5.11 Added Request codes. App D, App. E.3, E.3.1, E.3.2, E.3.3, App F. Updated fields in Listing Identification Folder. Ch and 5.23 Revised Appendixes D, G and H Relation between BME Data Feed Source ID and and MIC Code (ISO 10383). Added DNUM Special Values and Examples E.5.1 and E.5.2. Added new Date and Time format in Table 2-1 Data Type Definition for Fixed Length Field. See also E.3 Date and Time.Added Appendixes J and I.

3 BME Data Feed s Page 3 of 3 TABLE OF CONTENTS 1 INTRODUCTION HOW TO USE THIS SPECIFICATION GUIDE RELEVANT DOCUMENTS COMMUNICATION INTERFACE PRIVATE TCP/IP NETWORK TCP DELIVERY IP ADDRESS AND PORT NUMBER BACKUP SYSTEM BASIC CONCEPTS RELATION BETWEEN BME DATA FEED SOURCE ID AND AND MIC CODE (ISO 10383) REQUEST / RESPONSE STYLE MESSAGE-DRIVEN PROTOCOL CONNECTION MODE Broadcast Mode Interactive Mode Mixed Mode USER ENTITLEMENT DELIVERY MODE Tick-by-Tick Mode Refresh Mode MESSAGE RECOVERY TIME RESOLUTION PROCESSING LOGIC USER STATES LOGIN TO THE SYSTEM LOGOUT BY USER FORCED LOGOUT BY SYSTEM PROCESS BROADCAST DATA INTERACTIVE REQUEST/ REPLY Add Watch by Product Cancel News Retrieval Remove Watch by Product Retrieve News by Time Retrieve Static Data Retrieve Static Data by Time MESSAGE DESCRIPTION GENERAL MESSAGE STRUCTURE Folder/Field Organisation Folder/Field Structure BME DATA FEED MESSAGE STRUCTURE MESSAGE - ADD WATCH BY PRODUCT REQUEST MESSAGE - CANCEL INSTRUMENT DATA RETRIEVAL REQUEST MESSAGE - CANCEL NEWS RETRIEVAL REQUEST...45

4 BME Data Feed s Page 4 of MESSAGE - DATA REQUEST ACKNOWLEDGEMENT DATA MESSAGE - HEARTBEAT DATA MESSAGE - LOGIN ACKNOWLEDGEMENT DATA MESSAGE - LOGIN REQUEST MESSAGE - LOGOUT ACKNOWLEDGEMENT DATA MESSAGE - LOGOUT REQUEST MESSAGE - MESSAGE RECOVERY REQUEST MESSAGE - REFRESH NEWS DATA MESSAGE - REFRESH QUOTE LISTING DATA MESSAGE - REMOVE WATCH BY PRODUCT REQUEST MESSAGE - RESUME BROADCAST REQUEST MESSAGE - RETRIEVE NEWS BY TIME REQUEST MESSAGE - RETRIEVE STATIC DATA BY TIME REQUEST MESSAGE - RETRIEVE STATIC DATA REQUEST MESSAGE - STATIC REFRESH INSTRUMENT DATA MESSAGE - SYSTEM LOGOUT DATA MESSAGE - SYSTEM STATE DATA MESSAGE TICK-BY-TICK LISTING DATA MESSAGE TICK-BY-TICK NEWS DATA...67 APPENDIX A - REQUEST MESSAGES SUMMARY APPENDIX B - DATA MESSAGES SUMMARY APPENDIX C - SYSTEM FOLDER LIST APPENDIX D - SYSTEM FIELD DEFINITION APPENDIX E - DATA VALUE PRESENTATION E.1 BOOLEAN...76 E.2 BYTE STREAM...76 E.3 DATE AND TIME...76 E.3.1 BCD DATE TIME...76 E.3.2 BCD TIME...78 E.3.3 BME DATA FEED REQUETS...80 E.4 CHAR...80 E.5 DNUM...80 E.5.1 SPECIAL VALUES...82 E.5.2 EXAMPLES...82 E.6 INTEGER...83 E.7 NETWORK BYTE ORDER...83 E.8 STRING...83 APPENDIX F - MESSAGE FOLDERS - CONSTANT VALUES TABLE APPENDIX G - INSTRUMENT TYPE (SORTED BY VALUE) APPENDIX H - INSTRUMENT TYPE (SORTED BY DESCRIPTION) APPENDIX I - LOGIN EXAMPLE APPENDIX J - LISTING IDENTIFICATION FOLDER... 90

5 BME Data Feed s Page 5 of 5 TABLES Table 1-1 BME Data Feed relevant Documents...7 Table 4-1 User State Transition...18 Table 5-1 MLB Bits Value...36 Table 5-2 Field GRP Definition...37 Table 5-3 Data Type Definition for Fixed Length Field...38 Table 5-4 Data Type Definition for Variable Length Field...39 Table 5-5 Layout of a Message ID Folder...41 Table 5-6 All available Message IDs supported by the BME Data Feed System...42 Table A-1 Possible requests made by users that are logged on...68 Table B-1 Possible messages sent to users that are logged on...69 Table C-1 System Folder List...70 Table D-1 Field ID Definition...71 Table E-1 Boolean Value Definition...76 Table E-2 Data Types for Date Time Representation...80 Table E-3 Decimal Number Data Types...81 Table E-4 Special Values for Decimal Number Data Types (see IEEE 754)...82 Table E-5 Examples of DNUMs...82 Table E-6 Integer Data Types...83 Table E-7 Code Set Definition...83

6 BME Data Feed s Page 6 of 6 FIGURES Figure 2-1 Private TCP/IP Network...8 Figure 2-2 TCP Delivery...9 Figure 2-3 Production Configuration...10 Figure 3-1 Response & Response Style...11 Figure 3-2 Message Structure...12 Figure 4-1 User State Transition...17 Figure 4-2 Login to the System...21 Figure 4-3 Logout by User...23 Figure 4-4 Forced Logout by System...24 Figure 4-5 Process Broadcast Data...25 Figure 4-6 Add Watch by Product...26 Figure 4-7 Cancel News Retrieval...28 Figure 4-8 Remove Watch by Product...29 Figure 4-9 Retrieve News by Time...30 Figure 4-10 Retrieve Static Data...32 Figure 4-11 Retrieve Static Data by Time...34 Figure 5-1 Basic Message Structure...35 Figure 5-2 Message Length Structure...35 Figure 5-3 MLB-1 Structure...35 Figure 5-4 Folder/Field Organisation...36 Figure 5-5 Field/Folder Structure...37 Figure 5-6 Field Header Structure...37 Figure 5-7 Example of a Block Length Field...40 Figure 5-8 General Structure of a BME Data Feed Message...41 Figure E-1 Decimal Number Structure...81

7 BME Data Feed s Page 7 of 7 2 Introduction This document provides a complete technical overview on the communication interface, message format and handling conventions for processing data from BME Data Feed. BME Data Feed is used by Bolsas y Mercados Españoles (hereinafter referred to as BME) as data dissemination system (hereinafter referred to as the BME Data Feed System) for the dissemination of real-time price data to external users. The BME Data Feed is an entitlement-driven Feed transmitted via TCP/IP and point-to-point connections. It enables users to receive different types of real-time price data from different data sources in a single Feed. By subscribing to BME Data Feed information products, users are able to control what type of data they wish to receive from the Feed. Data can be delivered either in broadcast mode, interactive mode or in mixed mode. Different data quality options are available to suit different users need: tick-by-tick or periodic refresh. The Feed also provides data recovery support to users for restoring data that was lost due to an unexpected event, such as a communication breakdown. 2.1 How to use this specification guide Chapter 1 contains a table of contents with a short introduction and references to related documents. Chapter 2 describes the communication interface with which users are connected to the dissemination system. Chapter 3 describes the basic concept of BME Data Feed. Chapter 4 describes the general processing logic of how to make a data request and how to process responses. Chapter 5 describes in greater detail how to handle messages. Appendices at the end of the document provide a quick reference to useful data. 2.2 Relevant Documents Table 2-1 BME Data Feed relevant Documents Item Document 1 BME Data Feed Fields and Products 2 BME Data Feed Fields and Products Guidelines 3 BME Data Feed Compression Guidelines

8 BME Data Feed s Page 8 of 8 3 Communication Interface This section describes the communication interface that connects users to the BME Data Feed System. 3.1 Private TCP/IP Network The current BME Data Feed System as set up by BME allows users to connect through leased lines (main and backup line). To establish a TCP/IP connection via Leased Line, users are required to set up appropriate TCP/IP communication equipment on their side. BME Data Feed System Network TCP/IP on leased line BME User User X Figure 3-1 Private TCP/IP Network

9 BME Data Feed s Page 9 of TCP Delivery In order to access the BME Data Feed content, users have to establish a TCP connection to the BME Data Feed System. Once a connection is established, Feed data flows through this connection until the connection is interrupted. BME Data Feed System TCP Connection User X Figure 3-2 TCP Delivery 3.3 IP Address and Port Number In order to connect to the BME Data Feed System, users need to obtain a valid IP address and TCP port number from BME. BME may assign different IP addresses to different users. When connecting to the BME Data Feed System, users should always continue to use their assigned IP addresses, otherwise the system may reject their connection requests. A fixed TCP port number is used for the BME Data Feed. To avoid conflicts with existing registered ports, the assigned port number lies within the range of temporary ports outside the Internet Assigned Numbers Authority s (IANA) registered ports range.

10 BME Data Feed s Page 10 of Backup System There are two systems for backup purposes, running in different physical locations, which offer an identical level of service in parallel. Users will be given TWO IP addresses with which they can connect to the BME Data Feed System: 1 st IP address for connecting to Primary BME Data Feed System 2 nd IP address for connecting to Secondary BME Data Feed System Users are advised to design their application and configure their communication in such a way to allow for switching connections between these two sites whenever they need to. Recommendation: As BME Data Feed provides identical data streams via both BME Data Feed Systems, users shall connect to both BME Data Feed Systems in parallel with 2 users, using one of the 2 connections as primary data source. In case of an outage of the connection, which is used as primary data source, users shall switch to the second one as primary data source. No matter which of the 2 connections has an outage, the user shall try to reestablish the connection on this side as fast as possible. In the event that a connection to one BME Data Feed System cannot be established, users should switch with both userids to the BME Data Feed System that is available. Primary BME Data Feed System Secondary BME Data Feed System Private TCP/IP Network User X Figure 3-3 Production Configuration

11 BME Data Feed s Page 11 of 11 4 Basic Concepts 4.1 Relation between BME Data Feed Source ID and and MIC Code (ISO 10383) Within the BME Data Feed system, the so called SOURCE_NAME field will be delivered / handled to identify Listings with their trading venue. In many cases, the BME SOURCE_NAME is derived from the Market Identifier Code (MIC) as defined in ISO But: The BME Data Feed field SOURCE_NAME is not identical to the ISO MIC Code, so both fields are not comparable. 4.2 Request / Response Style The BME Data Feed supports a wide range of data requests. Chapter 4 provides a general description of the required processing logic on how to issue requests and handle responses. Requests and responses in the Feed take on the shape of BME Data Feed Messages. To make a request users have to send a message containing the appropriate request data, in a specific message layout. Upon completion, the BME Data Feed System transmits to users another message with the relevant response data in a different message layout. In both cases, users need to be very familiar with the structure of these types of messages and must know which data is stored inside which layout. This part is fully covered in chapter 5. BME Data Feed System Request Response User X Figure 4-1 Response & Response Style

12 BME Data Feed s Page 12 of Message-Driven Protocol The BME Data Feed adopts a message-driven protocol to control the exchange of data between the BME Data Feed System and its users. Messages are the basic communication unit. The protocol specifies rules on how messages are formatted and exchanged. The data inside a message is structured into folders and fields. A folder is a collection of related fields (or folders). A field contains the actual data with a description on how the data is stored. Data inside a message can be accessed by accessing the correct field in the relevant folder. Details with respect to the identification of folders and fields are provided in chapter 5.1, further information about folder structuring in chapter Important hint: the sequence of fields within a folder is never guaranteed. Thus, all examples for fields within a folder in this document only describe one possible sequence. Message Folder Folder Field Field Folder Folder Field Field Field Field Field Figure 4-2 Message Structure 4.4 Connection Mode The BME Data Feed System supports the following connection modes: Broadcast Mode Interactive Mode Mixed Mode Different connection modes control the type of requests that can be sent to the System, as well as the possible responses returned by the System. The connection mode is a pre-defined setting in the user s entitlement profile. The BME Data Feed System automatically determines the relevant connection mode for a user as soon as the connection has been established.

13 BME Data Feed s Page 13 of Broadcast Mode In Broadcast Mode, users receive directly data according to their entitled products. They have also the possibility to send recovery requests by time and date as well as outbound message keys. By referring to the user s entitlement profile, the BME Data Feed System is able to determine what data the user receives from the data feed Interactive Mode Interactive Mode gives users control over their entitled products. After login, they need to select the desired BME Data Feed products they want to receive from the BME Data Feed. For reference, see chapter Add watch by product request. They have also the possibility to send recovery requests by time and date as well as outbound message keys. The BME Data Feed System will not transmit any unrequested data. The BME Data Feed System has implemented the User Request Throttling mechanism to ensure that a single user is blocked from transmitting a flood of requests. When the limit is exceeded, the excessive requests will be suspended for service and it will take a long time before the user receives any reply. This does not affect other users and, unless a user tries to flood the BME Data Feed System intentionally, such incidents should occur rarely Mixed Mode As is the case with Broadcast Mode, the BME Data Feed System automatically determines and transmits the type of data requested by the user in Mixed Mode based on his entitlement profile. Users do not need to issue any request for the data. They also have the possibility to send recovery requests by time and date as well as outbound message keys. Mixed Mode users are given the option of defining the watch list of a session by reducing it on Product level. They have to provide a Remove Watch by Product Request in this case. They are allowed to make use of Add Watch by Product Request as well. Similar to Interactive Mode, the BME Data Feed System will guard the Feed against a flood of requests by applying the User Request Throttling mechanism (for details please refer to the previous section). 4.5 User Entitlement The BME Data Feed can supply many different types of price data from many different sources. Users may select the type of data they wish to receive from their own Feed connection. To do this, they must only subscribe to the information products that they are interested in. When processing the customer's login request, the BME Data Feed System uses the identification to check on the user s entitlement profile and determine the type of data that the user who has just logged on is allowed to receive.

14 BME Data Feed s Page 14 of Delivery Mode User entitlement also determines the quality of the data that users are entitled to receive. There are different types of data quality, which are controlled by the Delivery Mode concept. Price data can be delivered to users in any one of the following modes: Tick-by-Tick Mode Refresh Mode The following sections provide more details on each mode Tick-by-Tick Mode When data is delivered in tick-by-tick mode, every update or change in a field is transmitted immediately to users in their chronological order. Tick-by-Tick is applied for Trade prices, order book information and indices Refresh Mode Refresh is applied for fundamental updates in the morning, listing updates in the morning and daily statistics in the evening. BME Data Feed uses a time parameter to control the amount of data triggered by an individual Refresh Event: Fundamental and Listing Refreshes usually cover only information changed recently, e.g. within the last 5 days, whereas daily statistics are disseminated for all listings, no matter when the last update happened.

15 BME Data Feed s Page 15 of Message Recovery The BME Data Feed System provides a message recovery function for users who have lost messages due to whatever reason. Users may enter recovery mode as follows: During logon: in their logon request, users indicate that they wish to switch to recovery mode after a connection has been established. After the connection has been established: users issue a Message Recovery Request in order to switch to recovery mode. When users are in recovery mode, the BME Data Feed System will re-transmit messages that were sent earlier but where not received by the user. During this procedure, the real-time update is temporarily suspended. After all messages have been re-transmitted, the BME Data Feed System will generate a notification (Message - Data Request Acknowledgement Data) after which the real-time update is resumed. In order to request recovery users have to define a starting point for the re-transmission. For this parameter the following options are available: by Time / Date (optional) by Outbound Message Key The time option determines the message history by specifying a starting time. Messages that occurred on or after the specified time are re-transmitted. Please note that time details should be specified in Greenwich Mean Time (GMT). Optionally, the date can be submitted in combination with the time. If no date is specified with the recovery request, only data from the current GMT day is re-transmitted. Please note that time details for recovery always are supposed to be specified in Greenwich Mean Time (GMT), resp. universal time coordinated (UTC). Optionally, the date can be submitted in combination with the time. If no date is specified with the recovery request, only data of the current day based on time zone UTC +0 - is re-transmitted. If a given recovery time is in the future, BME Data Feed will switch to broadcast mode immediately. Outbound Message Key (OMK, also called OMID=Outbound Message ID) determines the message history by specifying the exact message from which to start the re-transmission. The specified message and the following messages are then re-transmitted. To specify the starting message, users must provide the OMK of the starting message. The OMK is found in every real-time broadcast message.

16 BME Data Feed s Page 16 of 16 Note: Please be aware that the Outbound Message Log (OML) file, on which recovery requests are based, is deleted on every business day. Recovery Requests with OMK parameter = 0: All messages of the current valid OML file will be recovered. The definition of OMK parameter = 0 ensures that a customer is able to recover all messages of the last business day over the weekend. 4.8 Time resolution BME Data Feed is technically able to process time formats with a resolution down to nanoseconds. In BME Data Feed Core, all fields of the two data types BCD_TIME and BCD_DATE_TIME are potentially affected. Customers have the opportunity to select between 3 different time resolution formats: 1. Time format in hundredth of seconds 2. Time format in microseconds 3. Time format in nanoseconds For this purpose different connectivity request types have been introduced (MID_CONNECTIVITY_REQUEST_MICRO and MID_CONNECTIVITY_REQUEST_NANO). Depending on the selected time format, the format has impact on all time related fields within BME Data Feed. E.g. OPEN_TIME, LOW_TIME, HIGH_TIME, CLOSE_TIME, LAST_TRADE_TIME, LAST_AUCTION_TIME, QUOTATION_TIME. See Appendix E.3 for more detailed explanation of requests and formats.

17 BME Data Feed s Page 17 of 17 5 Processing Logic 5.1 User States A user can be in any one of the following states: Disconnected Connected Broadcast User Recovery Broadcast (Broadcast User in Recovery Mode) Interactive User Recovery Interactive (Interactive User in Recovery Mode) Mixed Mode User Recovery Mixed (Mixed Mode User in Recovery Mode) The diagram below summarizes the possible state transition paths. DISCONNECTED TCP Connection / Disconnection CONNECTED Logon RECOVERY BROADCAST BROADCAST Request Recovery / Resume Broadcast RECOVERY INTERACTIVE INTERACTIVE Request Recovery / Resume Broadcast MIXED Request Recovery / Resume Broadcast RECOVERY MIXED Logout/ TCP Disconnection Figure 5-1 User State Transition The table below summarizes the characteristics of each state.

18 BME Data Feed s Page 18 of 18 Table 5-1 User State Transition State Description Remarks Disconnected User is not connected to the BME Data Feed System. User needs to establish physical connection before any data can be accessed. Possible state change = from Disconnected to Connected. Connected User is physically connected to the BME Data Feed System via TCP connection. In this state, the user will receive a system notification message indicating whether or not the system is ready. Three actions are possible: 1. Return to Disconnected state by disconnecting the TCP or physical connection. 2. Change to one of the three User modes by logging on without recovery. The user mode is pre-defined in the user profile and therefore not controlled by login parameters. 3. Change to Recovery Broadcast or Recovery Mixed mode by logging on with recovery. The entitled recovery mode is pre-defined in the user profile. Please note that Interactive Users should not log on with recovery, as their broadcast watch list has not been set up properly. Broadcast User User is logged on as Broadcast User Possible events and actions: 1. Change to Disconnected state by issuing logout request or upon receipt of forced logout message. 2. Change to Disconnected state upon abnormal breakdown of the TCP and physical connection. 3. Change to Recovery Broadcast state by issuing Recovery Request. 4. Broadcast data will be automatically received according to user entitlement. Recovery Broadcast User is physically connected to the BME Data Feed System via TCP connection. Based on the specified recovery option, the user will receive past messages transmitted by the BME Data Feed System. After all past messages have been transmitted, a notification message is generated. Then the BME Data Feed System automatically switches the user s state to Broadcast User. User might also issue Resume Broadcast request to switch to Broadcast User immediately.

19 BME Data Feed s Page 19 of 19 State Description Remarks Interactive User User is logged on as Interactive User Possible events and actions: 1. Change to Disconnected state by issuing logout request or upon receipt of forced logout message. 2. Change to Disconnected state upon abnormal breakdown of the TCP and physical connection. 3. Change to Recovery Interactive state by issuing Recovery Request. 4. Reception of appropriate broadcast data according to the watch list set up by the user. 5. Entitlement to all of the interactive requests supported by the system. Recovery Interactive User is physically connected to the BME Data Feed via TCP connection. User will receive past messages transmitted by the BME Data Feed System based on the specified recovery option. After all past messages have been transmitted, a notification message is generated. Then the BME Data Feed System automatically switches the state to Interactive User. Similar to real-time broadcast data, the recovery messages are filtered against the current watch list of the user. User might also issue Resume Broadcast to switch to Interactive User immediately. Mixed Mode User User is logged on as Mixed Mode User Possible events and actions: 1. Change to Disconnected state by issuing logout request or upon receipt of forced logout message. 2. Change to Disconnected state upon abnormal breakdown of the TCP and physical connection. 3. Change to Recovery Mixed state by issuing Recovery Request. 4. Automatic reception of broadcast data in accordance with user entitlement. 5. Entitlement to all of the interactive requests supported by the system.

20 BME Data Feed s Page 20 of 20 State Description Remarks Recovery Mixed User is physically connected to the BME Data Feed via TCP connection. User will receive past messages transmitted by the BME Data Feed System based on specified recovery option. After all past messages have been transmitted, a notification message is generated. Then the BME Data Feed System automatically switches state to Mixed User. Similar to real-time broadcast data, the recovery messages are filtered against the current watch list of the user. User might also issue Resume Broadcast to switch to Mixed User immediately. In order to access data, users must first establish a TCP connection. When this connection is established, the state of the user will change from Disconnected to Connected. The next step is to be acknowledged by the BME Data Feed System via the login process. A successful login will change the user s state from Connected to one of the following: Broadcast User Recovery Broadcast Interactive User Mixed Mode User Recovery Mixed If desired, users may change back to the Disconnected state by going through the logout procedure. The BME Data Feed may also force users to logout when necessary. When there is a problem with the TCP or physical connection, users may be forced to change from any of the above user states to Disconnected. Users only have access to the latest market data when they are in one of the 3 user states. In the recovery states, only past messages are transmitted.

21 BME Data Feed s Page 21 of Login to the System BMEDF Figure 5-2 Login to the System System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. Notify user of system state: either READY or MAINTENANCE. The message is sent when the TCP connection is first established or the system state changes. (Message Name, FIELD_NAME) System State Data SYS_STATE 2. If system state is READY, then request login. Login Request USER_ID PASSWORD 3. Acknowledge user login by sending login reply: either SUCCESSFUL or FAIL Login Acknowledgement Data RESPONSE_SUBJECT REQ_END_REASON

22 BME Data Feed s Page 22 of 22 System Actions & Reactions User Actions & Reactions Related Messages & Fields 4. If login is SUCCESSFUL, then users are ready to access market data. (Message Name, FIELD_NAME) Possible FAIL reasons could be: The BME Data Feed is not available Incorrect password Unknown user ID User already logged on BME Data Feed error In the event of an incorrect password or unknown user ID, the TCP connection will be terminated if the login fails 3 consecutive times or if the login period times out.

23 BME Data Feed s Page 23 of Logout by User BMEDF CEF USER Logout Request Logout Acknowledgement Data - Logout Successful Figure 5-3 Logout by User System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. Request for logout Logout Request (Message Name, FIELD_NAME) USER_ID 2. Acknowledge user logout by sending logout reply: always SUCCESSFUL Logout Acknowledgement Data RESPONSE_SUBJECT

24 BME Data Feed s Page 24 of Forced Logout by System BMEDF CEF USER System Logout Data Figure 5-4 Forced Logout by System System Actions & Reactions User Actions & Reactions Related Messages & Fields (Message Name, FIELD_NAME) 1. Send logout notification to user System Logout Data LOGOUT_REASON 2. Check reason for failure. Whatever reason it may be, users must log in again to be able to access market data when the system is ready for service. 5.5 Process Broadcast Data BMEDF

25 BME Data Feed s Page 25 of 25 Figure 5-5 Process Broadcast Data System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User has logged on successfully (Message Name, FIELD_NAME) 2. Send out broadcast data depending on the user login state and user entitlement All users that are logged on will receive system notification and heartbeat data. System State Data System Logout Data For Broadcast and Mixed Mode users, market data disseminated as broadcast data will be received depending on the user s entitlement. Heartbeat Data Tick-by-Tick Listing Data Refresh Quote Listing Data Static Refresh Instrument Data Interactive users will receive market data disseminated as broadcast data only after sending the watch request. Refer to subsequent sections for details. Tick-by-Tick News Data

26 BME Data Feed s Page 26 of Interactive Request/ Reply Add Watch by Product Figure 5-6 Add Watch by Product System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User requests to add watch for a product. This action is only available for Interactive and Mixed Mode users. (Message Name, FIELD_NAME) Add Watch by Product Request PRODUCT_ID 2. Add all listings covered by the entitled product to the user s watch list to enable the user to continuously receive related market data as broadcast data. Add all news sources of the product to the user news watch list for upcoming news broadcast. 3. When the required modifications Tick-by-Tick Listing Data Refresh Quote Listing Data Tick-by-Tick News Data

27 BME Data Feed s Page 27 of 27 System Actions & Reactions User Actions & Reactions Related Messages & Fields of the watch list are completed, a Data Request Acknowledgement Data message will be sent to the user to indicate that the Add Watch by Product request has been completed successfully. No Request ID will be added for the upcoming market data and news as broadcast data. (Message Name, FIELD_NAME) This is regarded as the signal for request completion. 4. Send out acknowledgement message to end the request prematurely due to the following reasons: Data Request Acknowledgement Data REQ_END_REASON Entitlement not covered Unauthorized request by Broadcast users BME Data Feed error Entitlement not covered is sent to end request for undefined products as well.

28 BME Data Feed s Page 28 of Cancel News Retrieval CEF BMEDF USER Cancel News Retrieval Request Data Request Acknowledgement Data - for target request to cancel Data Request Acknowledgement Data - for this cancellation request Figure 5-7 Cancel News Retrieval System Actions & Reactions User Actions & Reactions Related Messages & Fields 2. Send out acknowledgement message to end the target request to cancel 3. Send out acknowledgement message to end this cancellation request due to the following reasons: Completed successfully Invalid argument Unauthorized request by Broadcast users BME Data Feed error 1. User requests to cancel the previous news retrieval requests. This action is only available for Interactive and Mixed Mode users. The cancellation applies to the following requests Retrieve News by Time Request The specified news retrieval request to be cancelled does not exist. (Message Name, FIELD_NAME) Cancel News Retrieval Request REQUEST_ID_FOR_CANCEL Data Request Acknowledgement Data REQ_END_REASON Data Request Acknowledgement Data REQ_END_REASON

29 Data Request Acknowledgement Data This document is subject to copy rights BME Data Feed s Page 29 of Remove Watch by Product BMEDF CEF USER Remove Watch by Product Request Figure 5-8 Remove Watch by Product System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User requests to remove watch by product. (Message Name, FIELD_NAME) Remove Watch by Product Request This action is only available for Interactive and Mixed Mode users. PRODUCT_ID 2. Remove all related listings and news sources of a product from the user s watch list. Data Request Acknowledgement Data REQ_END_REASON Stop sending any related upcoming broadcast listing market data and news to the user. Send out acknowledgement message to end the request due to the following reasons: Completed successfully Unauthorised request by non-interactive users BME Data Feed error Unknown product is sent to end removal request of product that is not current in the watch list.

30 Data Request Acknowledgement Data This document is subject to copy rights BME Data Feed s Page 30 of Retrieve News by Time BMEDF CEF USER Retrieve News by Time Request Refresh News Data Figure 5-9 Retrieve News by Time System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User requests news retrieval for specific time range. This action is only available for Interactive and Mixed Mode users. (Message Name, FIELD_NAME) Retrieve News by Time Request SOURCE_NAME RETRIEVE_FROM RETRIEVE_TO User should note that both date and time are required to be supplied in RETRIEVE_FROM and RETRIEVE_TO for making the request. 2. Send out news data within specified time range. Again, everything that is transmitted is bound by user entitlement. Note that the watch list is not affected by this request. Refresh News Data When the last up-to-date refresh has been sent, label it as the last response. This is regarded as request completion. 3. Send out acknowledgement message to end the request prematurely due to the following reasons: Data Request Acknowledgement Data REQ_END_REASON

31 BME Data Feed s Page 31 of 31 System Actions & Reactions User Actions & Reactions Related Messages & Fields Completed successfully Entitlement not covered Unknown news source Unauthorised request by Broadcast users BME Data Feed error No relevant news is available in the specified time range. (Message Name, FIELD_NAME)

32 Data Request Acknowledgement Data This document is subject to copy rights BME Data Feed s Page 32 of Retrieve Static Data BMEDF CEF USER Retrieve Static Data Request Static Refresh Instrument Data Figure 5-10 Retrieve Static Data System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User requests retrieval of static data of an instrument. This action is only available for Interactive and Mixed Mode users. (Message Name, FIELD_NAME) Retrieve Static Data Request SYMBOL SOURCE_NAME 2. Send out instrument static data images for valid users in Static Refresh Instrument Data messages. Note that the watch list is not affected by this request. Static Refresh Instrument Data When the last up-to-date refresh has been sent, label it as the last response. Send out acknowledgement message to mark the completion of this request. Completed Successfully This is regarded as request completion. 3. Send out acknowledgement message to end the request prematurely due to the following reasons: Data Request Acknowledgement Data REQ_END_REASON Data Request Acknowledgement Data REQ_END_REASON

33 BME Data Feed s Page 33 of 33 System Actions & Reactions User Actions & Reactions Related Messages & Fields Entitlement not covered Unknown instrument Unauthorised request by Broadcast users BME Data Feed error (Message Name, FIELD_NAME)

34 Data Request Acknowledgement Data This document is subject to copy rights BME Data Feed s Page 34 of Retrieve Static Data by Time BMEDF CEF USER Retrieve Static Data by Time Request Static Refresh Instrument Data Figure 5-11 Retrieve Static Data by Time System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User requests retrieval of static data of all instruments that have been updated during the specific date range. (Message Name, FIELD_NAME) Retrieve Static Data by Time Request SOURCE_NAME RETRIEVE_DATE_FROM This action is only available for Interactive and Mixed Mode users. RETRIEVE_DATE_TO 2. Send out static data for all instruments that were updated during the specified date range. Again, everything that is transmitted is bound by user entitlement. When the last up-to-date refresh has been sent, label it as the last response. 3. Send out acknowledgement message to end the request prematurely due to the following reasons: This is regarded as request completion. Static Refresh Instrument Data Data Request Acknowledgement Data REQ_END_REASON Completed successfully Entitlement not covered Unauthorised request by Broadcast users BME Data Feed error No relevant static data is available in the specified time range.

35 BME Data Feed s Page 35 of 35 6 Message Description 6.1 General Message Structure A message consists of two segments: Message Length Message Content Figure 6-1 Basic Message Structure Message Content This segment contains the actual contents of the message. Its size is determined by the Message Length segment. Message Length This segment contains 1 to 3 bytes. They are MLB-1, MLB-2 and MLB-3 as shown in the diagram below. The encoded message length is always including the size of the length field itself. Byte MLB-1 is mandatory whilst the other two are optional, depending on the data in MLB-1. Byte 1 MLB-1 Byte 2 (optional) MLB-2 Byte 3 (optional) MLB-3 Byte MLB-1 has the following structure: Figure 6-2 Message Length Structure Bit 8 CF Bit Bit 7 & 6 MLB Bits Bit 5-1 Length Bits Figure 6-3 MLB-1 Structure CF Bit determines whether compressed data is stored in the Message Content segment. If set to OFF, the Message Content segment contains uncompressed data. If set to ON, the Message Content segment contains compressed data. Remark: If the CF bit is set on for compression, the compression feature works if the compression is needed. E.g. in case of too small line bandwidth and message queues. So the effect is that not every data block is compressed. Therefore every data block needs to be checked if the CF bit is set on for following compressed data or not for uncompressed data. MLB Bits determines the length of the Message Content segment.

36 BME Data Feed s Page 36 of 36 Table 6-1 MLB Bits Value MLB Bits Description 0 0 Message Content segment size is stored in MLB-1 only. Length bits: size of Message Content segment MLB-2: not required MLB-3: not required 0 1 Message Content segment size is stored in MLB-1 and MLB-2. Length bits: most significant bits (bit 9-13) MLB-2: remaining least significant bits (bit 1-8) MLB-3: not required 1 0 Message Content segment size is stored in MLB-1, MLB-2 and MLB-3. Length bits: most significant bits (bit 17-21) MLB-2: remaining least significant bits (bit 9-16) MLB-3: remaining least significant bits (bit 1-8) Folder/Field Organisation The contents of a message are stored inside the Message Content segment which is organised on the basis of the folder and field concept. The diagram below is an example of a message with contents structured in folders and fields: Message Length Message Content Folder Folder Field Field Folder Folder Field Field Field Field Field Figure 6-4 Folder/Field Organisation A folder is a logical collection of related fields. If necessary, it may also contain folders as shown in the diagram above. A field is the basic unit that carries the actual data. The data in the field is encoded depending on the type of data.

37 BME Data Feed s Page 37 of Folder/Field Structure Folder and field share the same structure which contains two segments: 2 bytes 0 N bytes Field Header Field Content Figure 6-5 Field/Folder Structure Field Content If it is a field, the Field Content segment stores the actual field data. If it is a folder, the Field Content segment stores the definition of fields/folders inside this folder. To determine whether the Field Content segment contains data for a field or for a folder, refer to the Field Header segment. The whole Field Header segment is also called 16-bit FID. Field Header The field header representing the 16-bit FID is the unique Field Identifier in BME Data Feed and has the following structure: 2 bits 4 bits 10 bits GRP TYPE 10bit FID Group Bits Type Bits FID bits Figure 6-6 Field Header Structure Field GRP designates whether it is a field or a folder. Table 6-2 Field GRP Definition Group Bits Description 0 0 The structure is a zero length field. 0 1 This structure is a fixed size field. 1 0 This structure is a variable size field. 1 1 This structure is a folder. Zero length fields denote a field without data. The size of the Field Content segment is 0.

38 BME Data Feed s Page 38 of 38 Fixed size field denotes a field whose size is implied by its data type. Refer to Field TYPE for more details. Variable size field denotes a field with variable length data. Both the size and the actual data are stored together in the Field Content segment. Refer to section Size of Variable Length Field for more details on processing such fields. A folder is treated as a variable size field. Its definition is stored in the Field Content segment whose size is determined by the same method applied to the variable size field. Refer to section Size of Variable Length Field for more details. Field TYPE indicates the type of data contained in a field. If field GRP indicates that it is a zero length field, field TYPE is ignored. If field GRP indicates that it is a fixed length field, then field TYPE is used to check on the type of data contained in this field in the following table. Table 6-3 Data Type Definition for Fixed Length Field Type Bits Data Type Size of Field Content 0x00 CHAR 1 0x01 Integer INT16 2 0x02 Integer INT32 4 0x03 Boolean 1 0x04 BCD Date and Time 8 0x04 BCD Date and Time (microseconds) 10 0x04 BCD Date and Time (nanoseconds) 12 0x05 BCD Date 4 0x06 BCD Time 4 0x06 BCD Time (microseconds) 6 0x06 BCD Time (nanoseconds) 8 0x07 DNUM16 3 0x08 DNUM32 5 0x09 DNUM64 9 0x0A BCD Date and Time UTC 12 0x0D INT64 8

39 BME Data Feed s Page 39 of 39 If field GRP indicates it is a variable length field, field TYPE is used to check the type of data in the field in the following table. For details on size, please refer to the section Size of Variable Length Field. Table 6-4 Data Type Definition for Variable Length Field Type Bit Data Type Size of Field Content 0x00 Byte Stream Variable 0x01 String Variable If field GRP indicates it is a folder, field TYPE is set to 0x00. More information on the data types mentioned in the above tables can be found in the chapter Data Value Presentation. Field NUMBER indicates the content in a field. It is no longer guaranteed that the 10-bit Number is unique over all data types, e.g. there will be only one field of data type DNUM32 with 10-bit Number value 2: 16-bit FID 0x6002 : Field of Data Type DNUM32 Best Ask But there may be fields of other data type with 10 Bit Number value 2, e.g. 16-bit FID 0x4002 : Field of Data Type CHAR 16-bit FID 0x5C02 : Field of Data Type DNUM16 16-bit FID 0x5802 : Field of Data Type BCD Time

40 BME Data Feed s Page 40 of 40 Size of Variable Length Field Size and contents are stored in the Field Content segment. Size information is stored in the Block Length Field. Block Length Field is always at the beginning of the Field Content segment. Block Length Field is a multi-bit integer presented as a series of bytes. The first byte of Block Length Field contains the most significant bits. The last byte of a Block Length Field contains the least significant bits. Each byte in the Block Length Field uses 7 bits only. The high order bit is reserved to indicate the end of a Block Length Field. If it is set to 1, the next following byte is part of the Block Length Field. If it is set to 0, this byte is the last byte of a Block Length Field. Size is determined by combining all bits in the Block Length Field to form a long integer. The integer value represents the data s actual size following the Block Length Field. The diagram below shows an example of Block Length Field. In the example, the first byte of the Block Length Field indicates that a second byte is to follow (high bit set to 1). The second byte indicates that this is the last byte of the Block Length Field (high bit set to 0). The precise length of the data following the Block Length Field is indicated by the 14-bit values stored across two bytes. The most significant bits (denoted here by X ) are in the first byte and the least significant bits (denoted here by Y ) are in the second byte. Block Length Field (2 bytes) First byte Bit X X X X X X X Second byte Bit Y Y Y Y Y Y Y Figure 6-7 Example of a Block Length Field

41 BME Data Feed s Page 41 of BME Data Feed Message Structure A message is defined as a collection of folders where the Message ID Folder is always the leading folder. BME Data Feed Message Folder Folder Folder Message ID Field Figure 6-8 General Structure of a BME Data Feed Message The layout of the Message ID folder is presented below: Table 6-5 Layout of a Message ID Folder Message ID Folder Field (Field ID) Description * MESSAGE_ID Message ID REQUEST_ID LAST_RESPONSE_INDICATOR Request ID Indicator of the last response message for the request it refers to. Remarks: * Mandatory Field Message ID is always the first field in the folder. Depending on the nature of the message there may be other fields that follow it. It is stored as a CHAR in the Message ID Field. Please refer to the Appendix for the actual values. Request ID is an optional field for the Message ID Folder. A message from the BME Data Feed System to a user might not carry a Request ID. This may be the case for those broadcast messages which are not delivered upon any request issued by the user. However, Request ID is essential for a request message. It is assigned by the person issuing the request. It should not be a duplicate of any outstanding or uncompleted request. Responses referring to a request should also carry the same Request ID for identification purposes.

42 BME Data Feed s Page 42 of 42 The Message ID Folder carries information that defines the nature of this message. In particular, it carries a Message ID field that provides the following indications: Message class to which it belongs Message format Message handling The Message ID defines the layout of a message and the possible folder for a message. The table below illustrates all available Message IDs which are currently supported by the BME Data Feed System. Table 6-6 All available Message IDs supported by the BME Data Feed System Message ID Description Messages Initiated by Users MID_CONNECTIVITY_REQUEST MID_CONNECTIVITY_REQUEST_MICRO MID_CONNECTIVITY_REQUEST_NANO MID_INSTRUMENT_REQUEST MID_NEWS_REQUEST MID_SPECIAL_REQUEST Connectivity request Connectivity request for microsecond time resolution Connectivity request for nanosecond time resolution Primary data request for instrument News request Special request Messages Generated by the BME Data Feed System MID_GENERAL_RESPONSE MID_HEARTBEAT MID_INSTRUMENT_DATA MID_LISTING_DATA MID_NEWS_DATA MID_SYSTEM_NOTIFICATION General response upon user request Heartbeat for user reference Primary data of instrument Market data of listing News information Notification generated by the System

43 BME Data Feed s Page 43 of Message - Add Watch by Product Request Purpose: Add all listings to the corresponding watch list covered by the specified BME Data Feed product. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_SPECIAL_REQUEST * REQUEST_ID * Special Request Folder * SPECIAL_REQUEST_SUBJECT WATCH_ADD_BY_PRODUCT * PRODUCT_ID BME Data Feed product id Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Scope is governed by user entitlement.

44 BME Data Feed s Page 44 of Message - Cancel Instrument Data Retrieval Request Purpose: Cancel non-completed instrument retrieval requests. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_INSTRUMENT_REQUEST * REQUEST_ID * Instrument Request Folder * INST_REQUEST_SUBJECT INSTRUMENT_DATA_RETRIEVAL_CANCELLAT ION * REQUEST_ID_FOR_CANCEL Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. The cancellation applies to the following retrieval requests Retrieve Static Data Request Retrieve Static Data by Time Request

45 BME Data Feed s Page 45 of Message - Cancel News Retrieval Request Purpose: Cancel non-completed news retrieval requests. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_NEWS_REQUEST * REQUEST_ID * News Request Folder * NEWS_REQUEST_SUBJECT NEWS_RETRIEVAL_CANCELLATION * REQUEST_ID_FOR_CANCEL Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. The cancellation applies to the following retrieval requests Retrieve News by Time Request

46 BME Data Feed s Page 46 of Message - Data Request Acknowledgement Data Purpose: This message acknowledges the receipt of user requests and returns the results. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_GENERAL_RESPONSE * REQUEST_ID * General Response Folder * RESPONSE_SUBJECT DATA_REQUEST_ACKNOWLEDGEMENT REQ_END_REASON 1 - BEGIN OF BROADCAST 2 - BEGIN OF RECOVERY 3 - CANCELLED BY USER 4 - COMPLETED SUCCESSFULLY -1 - BME DATA FEED ERROR -3 - ENTITLEMENT NOT COVERED -5 - INVALID ARGUMENT -6 - INVALID OUTBOUND_MESSAGE_KEY FOR RECOVERY -7 - INVALID RETRAN_TIME FOR RECOVERY -8 - UNAUTHORIZED REQUEST -9 - UNKNOWN INSTRUMENT UNKNOWN LISTING UNKNOWN NEWS SOURCE UNKNOWN PRODUCT REQUEST LIMIT EXCEED REQUEST WHILE RECOVERING RESUME WHILE NOT RECOVERING REQUEST TIMEOUT RECOVERY ABORT MISSING REQUEST ID

47 BME Data Feed s Page 47 of 47 Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. REQ_END_REASON indicates that the request is completed or provides the reason why the request was aborted. 3. LAST_RESPONSE_INDICATOR is provided if the message is the last of a series of messages (response to a particular request); e.g. if a recovery request has been completed and this message contains the transition on broadcast.

48 BME Data Feed s Page 48 of Message - Heartbeat Data Purpose: This message informs users that the system is up and running. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_HEARTBEAT * Heartbeat Folder * SYSTEM_TIME Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. This message is transmitted once a minute.

49 BME Data Feed s Page 49 of Message - Login Acknowledgement Data Purpose: This message acknowledges the receipt of a user login request and returns the results. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_GENERAL_RESPONSE * REQUEST_ID LAST_RESPONSE_INDICATOR * General Response Folder * RESPONSE_SUBJECT LOGIN_ACKNOWLEDGEMENT * REQ_END_REASON 5 - LOGIN SUCCESSFUL - BEGIN OF BROADCAST 6 - LOGIN SUCCESSFUL - BEGIN OF RECOVERY -1 - BME Data Feed ERROR -2 - BME Data Feed NOT AVAILABLE -3 - ENTITLEMENT NOT COVERED -4 - INCORRECT PASSWORD -5 - INVALID ARGUMENT -6 - INVALID OUTBOUND_MESSAGE_KEY FOR RECOVERY -7 - INVALID RETRAN_TIME FOR RECOVERY INVALID USER ID OR PASSWORD USER ALREADY LOGGED IN CURRENT DATE IS NOT COVERED BY SUBSCRIPTION PERIOD MISSING REQUEST ID Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. REQ_END_REASON indicates whether the login was successful or provides the reason for the failure.

50 BME Data Feed s Page 50 of Message - Login Request Purpose: This message is used to log in to the system. Users may initialise message recovery by Outbound Message Key or time. Users may also enable compression. In this case BME Data Feed will compress messages only in case of bandwidth bottlenecks. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_CONNECTIVITY_REQUEST or MID_CONNECTIVITY_REQUEST_MICRO or MID_CONNECTIVITY_REQUEST_NANO * REQUEST_ID * Connectivity Request Folder * CONNECTIVITY_REQUEST_SUBJECT LOGIN * USER_ID * PASSWORD OUTBOUND_MESSAGE_KEY MESSAGE_OFFSET RECOVERY_DATE RECOVERY_TIME ENABLE_COMPRESSION

51 BME Data Feed s Page 51 of 51 Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Depending on the desired time format there are 3 different Requests available. For further reference see also Ch. 3.7 and Appendix E3. 3. USER_ID and PASSWORD are assigned by the BME Data Feed Administration. 4. If the user supplies OUTBOUND_MESSAGE_KEY or RECOVERY_TIME, recovery request is assumed. However, the user should note that these two fields should not coexist. 5. If recovery by Outbound Message Key is requested, the user may also supply MESSAGE_OFFSET to define the recovery start position relative to the message specified by the OUTBOUND_MESSAGE_KEY. 6. Depending on the selected MESSAGE_ID value the client has to send the RECOVERY_TIME field with the selected time resolution. 7. The RECOVERY_TIME field has to be sent in GMT.

52 BME Data Feed s Page 52 of Message - Logout Acknowledgement Data Purpose: This message acknowledges the receipt of a user logout request and returns the results. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_GENERAL_RESPONSE * REQUEST_ID LAST_RESPONSE_INDICATOR * General Response Folder * RESPONSE_SUBJECT LOGOUT_ACKNOWLEDGEMENT * REQ_END_REASON 7 - LOGOUT SUCCESSFUL Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. REQ_END_REASON indicates that the logout was successful.

53 BME Data Feed s Page 53 of Message - Logout Request Purpose: This message is used to log out from the system. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_CONNECTIVITY_REQUEST * REQUEST_ID * Connectivity Request Folder * CONNECTIVITY_REQUEST_SUBJECT LOGOUT USER_ID Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. USER_ID is assigned by the BME Data Feed Administration.

54 BME Data Feed s Page 54 of Message - Message Recovery Request Purpose: Initialise message recovery by Outbound Message Key or time. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_SPECIAL_REQUEST * REQUEST_ID * Special Request Folder * SPECIAL_REQUEST_SUBJECT MESSAGE_RECOVERY OUTBOUND_MESSAGE_KEY MESSAGE_OFFSET RECOVERY_DATE RECOVERY_TIME Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. If the user supplies OUTBOUND_MESSAGE_KEY or RECOVERY_TIME, recovery request is assumed. However, the user should note that these two fields should not coexist. 3. If recovery by Outbound Message Key is requested, the user may also supply MESSAGE_OFFSET to define the recovery start position relative to the message specified by the OUTBOUND_MESSAGE_KEY. 4. Please note that this request is eligible for users of different connection modes. 5. The REQUEST_ID should have a value higher than zero. 6. Depending on the selected MESSAGE_ID value the client has to send the RECOVERY_TIME field with the selected time resolution. 7. The RECOVERY_TIME field has to be sent in GMT.

55 BME Data Feed s Page 55 of Message - Refresh News Data Purpose: This message contains a news refresh from a news source. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_NEWS_DATA * REQUEST_ID * News Identification Folder * NEWS_DATA_SUBJECT NEWS_DATA_REFRESH * NEWS_ID * SOURCE_NAME * News Folder * NEWS_HEADLINE NEWS_STORY NEWS_METADATA NEWS_TIME NEWS_SRC_TIME Product ID Folder PRODUCT_ID <more PRODUCT_ID fields> Remarks: Mandatory folders and fields are labelled with a leading asterisk.

56 BME Data Feed s Page 56 of Message - Refresh Quote Listing Data Purpose: This message contains quote refreshes. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_LISTING_DATA OUTBOUND_MESSAGE_KEY REQUEST_ID * Listing Identification Folder * LISTING_DATA_SUBJECT LIST_DATA_QUOTE_REFRESH * SOURCE_NAME * INSTRUMENT_TYPE * SYMBOL <any source-specific listing identification fields> Refer to document BME Data Feed Interface Specifications Appendix J - and BME Data Feed Fields and Products for field descriptions * Quote Folder * <any source-specific quote fields> Refer to document BME Data Feed Interface Specifications / Fields and Products for field descriptions Product ID Folder PRODUCT_ID <more PRODUCT_ID fields> Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. OUTBOUND_MESSAGE_KEY is only available for broadcast message. 3. REQUEST_ID is not available for broadcast message. 4. The SYMBOL of an instrument could be an ISIN (International Security Identification Number) or another product identifier code. 5. A Quote Folder can hold multiple fields, but no duplicates. They are source-specific and should be referenced in the document BME Data Feed Fields and Products.

57 BME Data Feed s Page 57 of Message - Remove Watch by Product Request Purpose: Remove all listings and news sources to the corresponding watch list covered by the specified product. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_SPECIAL_REQUEST * REQUEST_ID * Special Request Folder * SPECIAL_REQUEST_SUBJECT WATCH_REMOVE_BY_PRODUCT * PRODUCT_ID BME Data Feed product id. Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Scope is governed by user entitlement.

58 BME Data Feed s Page 58 of Message - Resume Broadcast Request Purpose: Resume broadcast from recovery. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_SPECIAL_REQUEST * REQUEST_ID * Special Request Folder * SPECIAL_REQUEST_SUBJECT RESUME_BROADCAST Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Please note that this request is available for users of different connection modes.

59 BME Data Feed s Page 59 of Message - Retrieve News by Time Request Purpose: Retrieve news that occurred during the specified time period from a news source. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_NEWS_REQUEST * REQUEST_ID * News Request Folder * NEWS_REQUEST_SUBJECT NEWS_TIME_RETRIEVAL * SOURCE_NAME * RETRIEVE_FROM * RETRIEVE_TO Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Scope is governed by user entitlement. 3. Time range is specified in BCD date time format. 4. The time resolution of the RETRIVE_FROM and RETRIVE_TO fields depends on the MESSAGE_ID value of the Login Request.

60 BME Data Feed s Page 60 of Message - Retrieve Static Data by Time Request Purpose: Retrieve static data of all instruments that were updated during the specified period. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_INSTRUMENT_REQUEST * REQUEST_ID * Instrument Request Folder * INST_REQUEST_SUBJECT STATIC_DATA_TIME_RETRIEVAL * SOURCE_NAME * RETRIEVE_DATE_FROM * RETRIEVE_DATE_TO Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Static data of all instruments that were updated during the specified date range will be transmitted. Scope is governed by user entitlement.

61 BME Data Feed s Page 61 of Message - Retrieve Static Data Request Purpose: Retrieve static data of an instrument. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_INSTRUMENT_REQUEST * REQUEST_ID * Instrument Request Folder * INST_REQUEST_SUBJECT STATIC_DATA_RETRIEVAL * SYMBOL * SOURCE_NAME Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. The SYMBOL of an instrument could be an ISIN (International Security Identification Number) or another product identifier code. 3. Futures contract requires expiry to identify the actual contract. It has to be added to the ISIN within the SYMBOL field, the two items are separated by a semicolon (e.g. TEFM09C; for a contract expiring in June, 2009) 4. Options contract requires expiry, category, generation number, and original strike price in addition to the ISIN to identify the actual contract. (e.g. T0 900X;201012;P;1;9 for a put option on Telefonica expiring in December, 2010, with a generation number of 1 and a strike of 9). This complete string has to be filled into the SYMBOL field. 5. Interactive Users may send one Static data request for an instrument during one second. Requests of higher frequency will be processed.

62 BME Data Feed s Page 62 of Message - Static Refresh Instrument Data Purpose: This message contains refreshes of the static data of an instrument. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_INSTRUMENT_DATA OUTBOUND_MESSAGE_KEY REQUEST_ID * Instrument Identification Folder * INSTRUMENT_DATA_SUBJECT INST_DATA_STATIC_REFRESH * SOURCE_NAME * INSTRUMENT_TYPE * SYMBOL <any source-specific listing identification fields> Refer to document BME Data Feed Interface Specifications Appendix J - and BME Data Feed Fields and Products for field descriptions * Static Data Folder * <any source-specific static fields> Refer to document Fields and Products for field descriptions Product ID Folder Product ID F PRODUCT_ID <more PRODUCT_ID fields> Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. OUTBOUND_MESSAGE_KEY is only available for broadcast message. 3. REQUEST_ID is not available for broadcast message. 4. The SYMBOL of an instrument could be an ISIN (International Security Identification Number) or another product identifier code. 5. A Static Data Folder can hold multiple fields, but no duplicates. They are sourcespecific and should be referenced in the document BME Data Feed Fields and Products.

63 BME Data Feed s Page 63 of Message - System Logout Data Purpose: This message forces users to log out. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_SYSTEM_NOTIFICATION * System Notification Folder * SYS_NOTIFICATION_SUBJECT LOGOUT_BY_SYSTEM * LOGOUT_REASON 1 - TERMINATED FOR MAINTENANCE 2 - TERMINATED BY OPERATOR 3 - LOGOUT BY REALTIME QUEUE FULL 4 - LOGOUT BY ENTITLEMENT CHANGE 5 - LOGIN PERIOD TIMEOUT -1 - AUTHORIZATION EXPIRED Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. This message is generated by the system when required. Users cannot control or predict when the system will generate such message. 3. In some cases e.g. slow connection lines, it might be possible that the LOGOUT_REASON as last message is not received by the user application.

64 BME Data Feed s Page 64 of Message - System State Data Purpose: This message indicates whether the system is ready for service or in maintenance mode. Direction: BMEDF USER Layout: Field Name Values * Message ID Folder * MESSAGE_ID MID_SYSTEM_NOTIFICATION * System Notification Folder * SYS_NOTIFICATION_SUBJECT SYSTEM_STATE * SYS_STATE READY MAINTENANCE Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. This message is sent when a TCP connection is first established. 3. This message is sent when the system s state changes.

65 BME Data Feed s Page 65 of Message Tick-by-Tick Listing Data Purpose: This message contains a tick-by-tick update (insertion) of the quote and intraday trades. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_LISTING_DATA * OUTBOUND_MESSAGE_KEY REQUEST_ID * Listing Identification Folder * LISTING_DATA_SUBJECT LIST_DATA_TICK_BY_TICK * SOURCE_NAME * INSTRUMENT_TYPE * SYMBOL <any source-specific listing identification fields> Refer to document BME Data Feed Interface Specifications Appendix J - and BME Data Feed Fields and Products for field descriptions * Quote Folder * <any source-specific quote fields> Refer to document BME Data Feed Interface Specifications / Fields and Products for field descriptions <more Quote Folder> Product ID F <any source-specific quote fields> Refer to document BME Data Feed BME Data Feed s / Fields and Products for field descriptions Product ID Folder Product ID F PRODUCT_ID <more PRODUCT_ID fields>

66 BME Data Feed s Page 66 of 66 Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. The SYMBOL of an instrument could be an ISIN (International Security Identification Number) or another product identification code. 3. A Quote Folder can hold multiple fields, but no duplicates. They are source-specific and should be referenced in the document BME Data Feed Fields and Products. 4. A Tick-by-Tick Listing Data message may contain multiple Quote Folders to accommodate multiple quotations of the listing. This feature is only available for those inbound sources which are capable of delivering multiple quotations of a listing in one message. 5. A Quote Folder may, but not necessarily, define an Intraday Tick. 6. Depending on the definition for each source, not every Quote Folder is sufficient to construct an Intraday Tick. 7. Not all data fields of a Quote Folder containing an Intraday Tick are associated with the tick. It totally depends on the source s definition of the tick. Please refer document BME Data Feed Fields and Products for the respective source definition. 8. An Intraday Tick in a Quote Folder must contain a TICK_ID and a TICK_ACTION_INDICATOR for the purpose of identification. Correction and deletion ticks contain a CORRECTION_TICK_ID to refer to the tick that is to be corrected as well. 9. There will be a REQUEST_ID if this is a recovered message.

67 BME Data Feed s Page 67 of Message Tick-by-Tick News Data Purpose: This message contains a tick-by-tick news update of a news source. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_NEWS_DATA * OUTBOUND_MESSAGE_KEY REQUEST_ID News Identification Folder * NEWS_DATA_SUBJECT NEWS_DATA_TICK_BY_TICK * NEWS_ID * SOURCE_NAME * News Folder * NEWS_HEADLINE NEWS_STORY NEWS_METADATA NEWS_TIME NEWS_SRC_TIME Product ID Folder PRODUCT_ID <more PRODUCT_ID fields> Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. There will be a REQUEST_ID if this is a recovered message.

68 BME Data Feed s Page 68 of 68 Appendix A - Request Messages Summary Table A-1 Possible requests made by users that are logged on Connection Mode Request Messages Broadcast Interactive Mixed Connectivity Request (MESSAGE_ID = MID_CONNECTIVITY_REQUEST) Login Request Logout Request Instrument Requests (MESSAGE_ID = MID_INSTRUMENT_REQUEST) Retrieve Static Data Request Retrieve Static Data by Time Request Cancel Instrument Data Retrieval Request News Requests (MESSAGE_ID = MID_NEWS_REQUEST) Retrieve News by Time Request Cancel News Retrieval Request Special Requests (MESSAGE_ID = MID_SPECIAL_REQUEST) Add Watch by Product Request Remove Watch by Product Request Message Recovery Request Resume Broadcast Request

69 BME Data Feed s Page 69 of 69 Appendix B - Data Messages Summary Table B-1 Possible messages sent to users that are logged on Connection Mode Data Messages Broadcast Interactive Mixed System Notification Messages (MESSAGE_ID = MID_SYSTEM_NOTIFICATION) System State Data System Logout Data Heartbeat Message (MESSAGE_ID = MID_HEARTBEAT) Heartbeat Data Listing Data Messages (MESSAGE_ID = MID_LISTING_DATA) Tick by Tick Listing Data Refresh Quote Listing Data Instrument Data Messages (MESSAGE_ID = MID_INSTRUMENT_DATA) Static Refresh Instrument Data News Data Messages (MESSAGE_ID = MID_NEWS_DATA) Tick-by-Tick News Data Refresh News Data General Response Messages (MESSAGE_ID = MID_GENERAL_RESPONSE) Login Acknowledgement Data Logout Acknowledgement Data Data Request Acknowledgement Data

70 BME Data Feed s Page 70 of 70 Appendix C - System Folder List Table C-1 System Folder List Folder CONNECTIVITY_REQUEST_FOLDER GENERAL_RESPONSE_FOLDER 16bit FID C2BE C2C1 HEARTBEAT_FOLDER C2C2 INSTRUMENT_IDENTIFICATION_FOLDER INSTRUMENT_REQUEST_FOLDER LISTING_IDENTIFICATION_FOLDER LISTING_REQUEST_FOLDER MESSAGE_ID_FOLDER C2C3 C2C4 C2C9 C2CA C2CC NEWS_FOLDER C2CD NEWS_IDENTIFICATION_FOLDER NEWS_REQUEST_FOLDER PRODUCT_ID_FOLDER C2CE C2CF C2D1 QUOTE_FOLDER C2D2 SPECIAL_REQUEST_FOLDER STATIC_DATA_FOLDER SYSTEM_NOTIFICATION_FOLDER C2D3 C2D4 C2D5

71 BME Data Feed s Page 71 of 71 Appendix D - System Field Definition Table D-1 Field ID Definition Field Data Type Description 16bit FID CONNECTIVITY_REQUEST_SUBJECT CHAR The actual subject of the request LOGIN LOGOUT EXPIRY STRING Expiry year and month of the contract, in the format YYYYMM. GENERATION_NUMBER CHAR Generation number of options. Valid range = INST_REQUEST_SUBJECT CHAR Type of static data request INSTRUMENT_DATA_SUBJECT CHAR The type of data contained in this message. 432A INST_DATA_STATIC_REFRESH INSTRUMENT_TYPE CHAR A value representing the instrument type of the listing or instrument LAST_RESPONSE_INDICATOR N/A (Empty) Indicator of the last response message for the request to which it refers. 032B LISTING_DATA_SUBJECT CHAR The type of data contained in this message. 432C LIST_DATA_TICK_BY_TICK LIST_DATA_QUOTE_REFRESH LOGOUT_REASON STRING Reason for system logout 872E 1 - TERMINATED FOR MAINTENANCE 2 - TERMINATED BY OPERATOR 3 - LOGOUT BY REAL-TIME QUEUE FULL 4 - LOGOUT BY ENTITLEMENT CHANGE 5 - LOGIN PERIOD TIMEOUT -1 - AUTHORISATION EXPIRED MESSAGE_ID CHAR Message ID 4331 MID_SYSTEM_NOTIFICATION MID_HEARTBEAT MID_CONNECTIVITY_REQUEST MID_CONNECTIVITY_REQUEST_MICRO MID_CONNECTIVITY_REQUEST_NANO MID_NEWS_REQUEST MID_SPECIAL_REQUEST MID_LISTING_DATA MID_INSTRUMENT_DATA MID_NEWS_DATA MID_GENERAL_RESPONSE

72 BME Data Feed s Page 72 of 72 Field Data Type Description 16bit FID MESSAGE_OFFSET INT32 Specifies the relative position for requesting message recovery by Outbound Message Key. NEWS_DATA_ SUBJECT CHAR The type of data contained in this message. 4B NEWS_DATA_TICK_BY_TICK NEWS_DATA_REFRESH NEWS_HEADLINE STRING News headline NEWS_ID INT32 ID given by news source for identification. 4B58 NEWS_METADATA STRING Meta-data content NEWS_REQUEST_SUBJECT CHAR The actual subject of the request: 433A NEWS_TIME_RETRIEVAL NEWS_RETRIEVAL_CANCELLATION NEWS_SRC_TIME BCD Date Time News, time-stamped by source. 533E NEWS_STORY STRING News story content. 873F NEWS_TIME BCD Date Time News, time-stamped by the BME Data Feed System OPTION_CATEGORY CHAR P Put option. C Call option ORIGINAL_STRIKE_PRICE DNUM32 Original strike price of options OUTBOUND_MESSAGE_KEY INT64 Identification key of a BME Data Feed outbound message (OMK, OMID) PASSWORD STRING Login password assigned by the BME Data Feed Administration. PRODUCT_ID STRING BME Data Feed Product ID to which this market data message refers RECOVERY_DATE BCD Date Specifies the date for the recovery request RECOVERY_TIME BCD Time Specifies the time for requesting message recovery. Please note that this field should be in GMT. REQ_END_REASON STRING Reason for ending the request: 1 - BEGIN OF BROADCAST 2 - BEGIN OF RECOVERY 3 - CANCELLED BY USER 4 - COMPLETED SUCCESSFULLY 5 - LOGIN SUCCESSFUL - BEGIN OF BROADCAST 6 - LOGIN SUCCESSFUL - BEGIN OF RECOVERY 7 - LOGOUT SUCCESSFUL 5B

73 BME Data Feed s Page 73 of 73 Field Data Type Description 16bit FID -1 - BME DATA FEED ERROR -2 - BME DATA FEED NOT AVAILABLE -3 - ENTITLEMENT NOT COVERED -4 - INCORRECT PASSWORD -5 - INVALID ARGUMENT -6 - INVALID OUTBOUND_MESSAGE_KEY FOR RECOVERY -7 - INVALID RETRAN_TIME FOR RECOVERY -8 - UNAUTHORIZED REQUEST -9 - UNKNOWN INSTRUMENT UNKNOWN LISTING UNKNOWN NEWS SOURCE UNKNOWN PRODUCT INVALID USER ID OR PASSWORD USER ALREADY LOGGED IN REQUEST LIMIT EXCEED REQUEST WHILE RECOVERING RESUME WHILE NOT RECOVERING REQUEST TIMEOUT RECOVERY ABORT CURRENT DATE IS NOT COVERED BY SUBSCRIPTION PERIOD MISSING REQUEST ID MISSING SOURCE_NAME UNKNOWN SOURCE OR MISSING ENTITLEMENT NO SYMBOL OR SERIES FOUND TOO MANY SYMBOLS (PER MESSAGE) TOO MANY SYMBOLS (IN TOTAL) RESPONSE_SUBJECT CHAR The type of response to which this message refers: 4345 LOGIN_ACKNOWLEDGEMENT LOGOUT_ ACKNOWLEDGEMENT DATA_REQUEST_ ACKNOWLEDGEMENT

74 BME Data Feed s Page 74 of 74 Field Data Type Description 16bit FID RETRIEVE_DATE_FROM BCD Date Date from which the retrieval start RETRIEVE_DATE_TO BCD Date Date on which the retrieval ends RETRIEVE_FROM BCD Date Time Date and time from which the retrieval starts RETRIEVE_TO BCD Date Time Date and time on which the retrieval ends. 534B REQUEST_ID INT32 Request ID chosen by user. It must not be a duplicate of any uncompleted request of the system. 4B4C Request ID of the request to which this message is a response. REQUEST_ID_FOR_CANCEL INT32 Request ID of the uncompleted request for cancelling. SOURCE_NAME STRING BME Data Feed source name. Source is a logical grouping of data in the BME Data Feed System. It usually represents the origin or supplier of the data. For example, the market data of a listing is usually supplied by an exchange. SPECIAL_REQUEST_SUBJECT CHAR The actual subject of the request: 4B4D 874E 4350 WATCH_ADD_BY_PRODUCT WATCH_REMOVE_BY_PRODUCT MESSAGE_RECOVERY RESUME_BROADCAST SYMBOL STRING Symbol (name) of the instrument. International Security Identification Number (ISIN). SYS_NOTIFICATION_SUBJECT CHAR Subject of the user notification: SYSTEM_STATE LOGOUT_BY_SYSTEM SYS_STATE STRING The state of the BME Data Feed System SYSTEM_TIME BCD Time System time at which the message is generated. 5B54 TICK_ID INT32 Tick ID unique to a listing within a day. 4B55 USER_ID STRING User identification assigned by the BME Data Feed Administration ENABLE_COMPRESSION N/A (Empty) BME Data Feed is enabled to compress outbound data. 031F SECURITY_ID STRING MEFF Contract group CONTRACT_SIZE DNUM32 Contract size of the derivatives 6006 EXERCISE_STYLE STRING Type of exercise of the security E European A American 85CC

75 BME Data Feed s Page 75 of 75 Field Data Type Description 16bit FID FLEXIBLE_IND BOOL Indicates if the security has been defined as flexible according to non-standard means. 4C03 Y Flexible N Standard (default)

76 BME Data Feed s Page 76 of 76 Appendix E - Data Value Presentation This chapter summarises all possible data types supported by the BME Data Feed. E.1 Boolean Boolean data field contains ONE byte that may have the following possible values: Table E-1 Boolean Value Definition Value Meaning 0 FALSE/NO/OFF 1 TRUE/YES/ON E.2 Byte stream The byte stream data field contains binary data. Its length is variable. Refer to section Size of Variable Length Data Type for details on how to determine the size of a byte stream data field. E.3 Date and Time Fields BCD_TIME and BCD_DATE_TIME will be extended internally with BME Data Feed R9.0. BCD_TIME will internally be 8 Bytes and BCD_DATE_TIME will internally be 12 Bytes long. Before BME Data Feed R9.0 the length of the time component was 4 Bytes and 8 Bytes. In order to find all affected fields please cf. BME Data Feed Fields and Products, filter column Format for those fields of data types BCD_DATE_TIME or BCD_TIME. The BME Data Feed client can decide via Login Request which data format will be used for the time representation. With BME Data Feed R13.0 has been introduced a new Date and Time format named BCDDateTimeUTC, it has the same format that current BCDDateTime (12 Bytes (4 Bytes Date + 8 Bytes Time)), but it is always in UTC. E.3.1 BCD Date Time This data type encodes both date and time information inside a single field and has the following characteristics: 12-byte internal to represent both DATE and TIME First 4-byte integer is the value for DATE Last 8-byte integer is the value for TIME Both DATE and TIME are in BCD format. DATE offers precision up to the year BCD format is in YYYYMMDD

77 BME Data Feed s Page 77 of 77 TIME is represented in the format HHMMSSNNNNNNNNNN where HHMMSS is in 24-hour format. NNNNNNNNNN values represents hundredth, micro or nanoseconds. A value of 0xFFFFFFFF in DATE implies NO DATE A value of 0xFFFFFFFF in TIME implies NO TIME. Examples of BCD Date Time Data Type

78 BME Data Feed s Page 78 of 78 E.3.2 BCD Time 8-byte internal to represent extended TIME down to nanoseconds. TIME is in BCD format. Customers have the choice between 3 different formats of delivery via BME Data Feed Core: Existing time format (hundredth of seconds). BCD_TIME format 4 Bytes BCD_DATE_TIME format 8 bytes Time format in microseconds. BCD_TIME format 6 Bytes BCD_DATE_TIME format 10 bytes Time format in nanoseconds (lowest digit expected to be always 0). BCD_TIME format 6 Bytes BCD_DATE_TIME format 10 bytes The Fields ID for each field will be the same for all 3 options. Overview: Formats and content of time fields

79 BME Data Feed s Page 79 of 79 The table below assumes that only TIME in BCD format is stored inside the field. Please refer to the section BCD Date Time for details on how time information is encoded. Example for BCD_TIME The difference in which time format the data is delivered, depends on the client connecting process. During the Login there are three different values available: 1. MID_CONNECTIVITY_REQUEST 2. MID_CONNECTIVITY_REQUEST_MICRO 3. MID_CONNECTIVITY_REQUEST_NANO

80 BME Data Feed s Page 80 of 80 E.3.3 BME Data Feed Requets The choice of the required format of time fields within a session has to be provided with the Login Request. In order no to force customers to change anything within their application in case they want to receive time fields in an unchanged format there will be separate types of message for Login Request available. A client using the existing Login request will receive time information in hundredth seconds resolution. For the 2 new options there will be new Login Request. As the time resolution is expected to be the same for messages disseminated by BME Data Feed and for messages sent to BME Data Feed by the client, any time field within the new Login Resquests has to be in the appropriate format. In particular, the parameter RECOVERY_TIME has to be provided in the appropriate format. The following table defines the respective BME Data Feed messages. Request Affected Field Resolution Login Request MID_CONNECTIVITY_REQUEST Login Request Micro MID_CONNECTIVITY_REQUEST_MICRO Login Request Nano MID_CONNECTIVITY_REQUEST_NANO RECOVERY_TIME FID 0x5B61 RECOVERY_TIME FID 0x5B61 RECOVERY_TIME FID 0x5B61 Hundredths Microseconds Nanosecons Possible data types for representing date and time information are listed in the table below. Table E-2 Data Types for Date Time Representation Data Type Length Precision Internal Representation BCD Date Time 12 bytes YYYY/MM/DD HH:MM:SS.SS.NNNNNNNNNN BCD BCD Date 4 bytes YYYY/MM/DD BCD BCD Time 8 bytes HH:MM:SS.SS.NNNNNNNNNN BCD E.4 CHAR CHAR data type field contains single-byte characters only. There are two ways to express its value: As a number: value is between As a presentable ASCII character: for example, A E.5 DNUM Decimal Number (DNUM) is another encoding methodology for representing numeric values. This encoding method has the following characteristics:

81 BME Data Feed s Page 81 of 81 It stores a value without precision loss It has a fixed size storage It supports decimal values only The diagram below shows the structure of a Decimal Number. 1 Byte 2, 4, or 8 Bytes E Mantissa Exponent A DNUM value is composed of two parts: Figure E-1 Decimal Number Structure Exponent Mantissa Exponent is a single-byte signed integer that defines the order of magnitude of base 10 of the number. It ranges from between -128 and 127. Mantissa is a 2, 4, or 8-byte signed integer that contains the value of the number. Actual Value = Mantissa * 10Exponent The BME Data Feed supports three kinds of DNUMs: Table E-3 Decimal Number Data Types Type BYTE Mantissa Range DNUM16 3 (-2 15 ) (2 15-1) DNUM32 5 (-2 31 ) (2 31-1) DNUM64 9 (-2 63 ) (2 63-1)

82 BME Data Feed s Page 82 of 82 E.5.1 Special Values Table E-4 Special Values for Decimal Number Data Types (see IEEE 754) DNUM16 DNUM32 DNUM64 Exponent Mantissa Exponent Mantissa Exponent Mantissa NoValue ,999, ,999,999,999,999, ,999, ,999,999,999,999,999 NaN E.5.2 Examples Table E-5 Examples of DNUMs Representation Actual Value Type Exponent Mantissa DNUM16 FE DNUM NoValue DNUM DNUM16 7F 03 E7 - DNUM16 7F FC 19 NaN DNUM DNUM32 FE DNUM32 FE FF ED DNUM32 04 FF FF CF C7 NoValue DNUM DNUM32 7F 3B 9A C9 FF - DNUM32 7F C NaN DNUM DNUM64 FE DNUM64 FE FF FF FF FF FF ED DNUM64 FD F 71 FB 04 CB DNUM64 02 FF FF FE E0 8E 04 FB 35 NoValue DNUM DNUM64 7F 0D E0 B6 B3 A7 63 FF FF - DNUM64 7F F2 1F 49 4C 58 9C NaN DNUM

83 BME Data Feed s Page 83 of 83 E.6 Integer The System supports the following kinds of signed integers: Table E-6 Integer Data Types Type BYTE Range INT16 2 (-2 15 ) (2 15-1) INT32 4 (-2 31 ) (2 31-1) INT64 8 (-2 63 ) (2 63-1) The byte order of the signed integer type follows the standard described in the section Network Byte Order. E.7 Network Byte Order When transmitting a numeric data type, the BME Data Feed System adopts the following Network Byte Order standard: High order byte of high order bits is transmitted first. For example, for an INT16 data field with value 0x0F0A, byte 0x0F is transmitted first, followed by byte 0x0A. E.8 String The string data type is used to store a text string. Basic facts: If the highest bit of the first byte is OFF, then the whole string is assumed to be an ASCII string. If the highest bit of the first byte is ON, then the first byte itself is a code set indicator which indicates the code set of that string (see table below): Table E-7 Code Set Definition Code Set Indicator Code Set 0x81 Big 5 0x82 0x83 0x84 0x85 GB JIS Shift JIS Unicode 0x86 ISO x87 0x88 ISO (Latin-1) ISO (Latin-15)

84 BME Data Feed s Page 84 of 84 Appendix F - Message Folders - constant values table MESSAGE_ID Value MID_SYSTEM_NOTIFICATION 1 MID_HEARTBEAT 2 MID_CONNECTIVITY_REQUEST MID_CONNECTIVITY_REQUEST_MICRO MID_CONNECTIVITY_REQUEST_NANO 3 (regular time format) 14 (time format for micro seconds) 15 (time format for nanoseconds MID_INSTRUMENT_REQUEST 5 MID_NEWS_REQUEST 6 MID_SPECIAL_REQUEST 7 MID_LISTING_DATA 9 MID_INSTRUMENT_DATA 10 MID_NEWS_DATA 11 MID_GENERAL_RESPONSE 12 SYS_NOTIFICATION_SUBJECT Value SYSTEM_STATE 1 LOGOUT_BY_SYSTEM 2 CONNECTIVITY_REQUEST_SUBJECT Value LOGIN 1 LOGOUT 2 INST_REQUEST_SUBJECT Value STATIC_DATA_RETRIEVAL 1 STATIC_DATA_TIME_RETRIEVAL 2 INSTRUMENT_DATA_RETRIEVAL_CANCELLATION 4 NEWS_REQUEST_SUBJECT Value NEWS_TIME_RETRIEVAL 3 NEWS_RETRIEVAL_CANCELLATION 5

85 BME Data Feed s Page 85 of 85 SPECIAL_REQUEST_SUBJECT Value WATCH_ADD_BY_PRODUCT 1 WATCH_REMOVE_BY_PRODUCT 2 MESSAGE_RECOVERY 3 RESUME_BROADCAST 4 LISTING_DATA_SUBJECT Value LIST_DATA_TICK_BY_TICK 1 LIST_DATA_QUOTE_REFRESH 4 LIST_DATA_INTRADAY_REFRESH 7 (not used) INSTRUMENT_DATA_SUBJECT Value INST_DATA_STATIC_REFRESH 1 NEWS_DATA_ SUBJECT Value NEWS_DATA_TICK_BY_TICK 1 NEWS_DATA_REFRESH 2 RESPONSE_SUBJECT Value LOGIN_ACKNOWLEDGEMENT 1 LOGOUT_ACKNOWLEDGEMENT 2 DATA_REQUEST_ACKNOWLEDGEMENT 3

86 BME Data Feed s Page 86 of 86 Appendix G - Instrument Type (sorted by value) Description (sorted by value) Value Roll-over 2 (50) Growth Companies 3 (51) Savings Banks Participations 4 (52) Open Outcry (Floor markets) 5 (53) Market State A (65) Bond B (66) Certificates C (67) Funds D (68) Equity E (69) Future Contract F (70) Future Product G (71) Sicavs H (72) Swap K (75) Index I (73) News N (78) Option Contract O (79) Strategy Q (81) Subscription Rights R (82) Other Security (incl. Participation certificates) S (83) Option Product U (85) Warrant W (87) Venture Capital Funds Z (90) Notes: The value A (65) Market State is the instrument type used for Market Halt messages Instruments with value S (83) can be bonds or equities or indices etc. But the value S may be assigned to them owing to internal processing within the BME Data Feed System. If customers want to use real instrument types in their applications we recommend to use reference data fields instead (SECURITY_GROUP_ID, SECURITY_TYPE, SECURITY_ID, EXERCISE_STYLE, FLEXIBLE_IND).

87 BME Data Feed s Page 87 of 87 Appendix H - Instrument Type (sorted by description) Description Value Bond B (66) Certificates C (67) Equity E (69) Funds D (68) Future Contract F (70) Future Product G (71) Growth Companies 3 (51) Index I (73) Market State A (65) News N (78) Open Outcry (Floor markets) 5 (53) Option Contract O (79) Option Product U (85) Other Security (incl. Participation certificates) S (83) Roll-over 2 (50) Savings Banks Participations 4 (52) Strategy Q (81) Sicavs H (72) Swap K (75) Subscription Rights R (82) Venture Capital Funds Z (90) Warrant W (87) Notes: The value A (65) Market State is the instrument type used for Market Halt messages Instruments with value S (83) can be bonds or equities or indices etc. But the value S may be assigned to them owing to internal processing within the BME Data Feed System. If customers want to use real instrument types in their applications we recommend to use reference data fields instead (SECURITY_GROUP_ID, SECURITY_TYPE, SECURITY_ID, EXERCISE_STYLE, FLEXIBLE_IND).

88 BME Data Feed s Page 88 of 88 Appendix I - Login Example Example for a Login Request with time resolution micro seconds, USER_ID USER1234 and PASSWORD PASS5678. Coding of Message ID Folder The folder contains two fixed size fields, the MESSAGE_ID field and the REQUEST_ID field. The value used for the message ID is MID_CONNECTIVITY_REQUEST_MICRO (Type: CHAR). The value used for the request ID is 1 (Type: INT32). Coding of the Connectivity Request Folder The folder contains three mandatory fields, the CONNECTIVITY_REQUEST_SUBJECT, the USER_ID and the PASSWORD. The latter two are variable length fields. The length of both fields can be coded in one byte. Coding of the USER_ID field: Coding of the PASSWORD field:

89 BME Data Feed s Page 89 of 89 Coding of complete Connectivity Request Folder: The length of the folder contents is the summary of the coding of the fields within the folder: 3 Byte for the CONNECTIVITY_REQUEST_SUBJECT and USER_ID and PASSWORD each with 11 Byte, in total 25 byte. Coding of the complete message: The contents length of the message is 12 (length of Message ID Folder) plus 28 (length of Connectivity Request Folder) = 40. This is more than 31. Thus, a 2 byte Message Length Block (MLB) is needed. The coding of the MLB: The complete message will be coded as:

BME Data Feed Fields and Products Guidelines

BME Data Feed Fields and Products Guidelines BME Data Feed Fields and Products Document Name: BME Data Feed Fields and Products Version: 1.0 Related to: BME Data Feed Release 5.5 Last update: BME Fields and Products Page 2 of 13 REVISION HISTORY

More information

US Options Complex Multicast TOP Specification

US Options Complex Multicast TOP Specification US Options Complex Multicast TOP Specification Version 1.0.12 March 23, 2018 Contents 1 Introduction... 5 1.1 Overview... 5 1.2 Feed Connectivity Requirements... 5 1.3 Symbol Ranges, Units, and Sequence

More information

US Options Complex Multicast TOP Specification

US Options Complex Multicast TOP Specification US Options Complex Multicast TOP Specification Version 1.0.4 September 1, 2017 Contents 1 Introduction... 5 1.1 Overview... 5 1.2 Feed Connectivity Requirements... 5 1.3 Symbol Ranges, Units, and Sequence

More information

Chi-X Japan CHIXOE Interface Specification

Chi-X Japan CHIXOE Interface Specification Chi-X Japan Trading System Document ID: JPCX-L3-D-022 9-Nov-2017 Version 1.8 CONTENTS 1 Introduction... 1 1.1 Relevant documents... 1 1.2 Revision History... 1 2 Data Types... 2 2.1 Integer... 2 2.2 Alpha...

More information

US Options Multicast Top Specification. Version 1.2.2

US Options Multicast Top Specification. Version 1.2.2 US Options Multicast Top Specification Version 1.2.2 December 21, 2018 Contents 1 Introduction... 5 1.1 Overview... 5 1.2 Feed Connectivity Requirements... 6 1.3 Symbol Ranges, Units, and Sequence Numbers...

More information

US Options Multicast Top Specification. Version 1.1.6

US Options Multicast Top Specification. Version 1.1.6 US Options Multicast Top Specification Version 1.1.6 March 23, 2018 Contents 1 Introduction... 5 1.1 Overview... 5 1.2 Feed Connectivity Requirements... 5 1.3 Symbol Ranges, Units, and Sequence Numbers...

More information

US Options Complex Multicast PITCH Specification

US Options Complex Multicast PITCH Specification Multicast PITCH Specification Version 2.0.9 March 23, 2018 Contents 1 Introduction... 5 1.1 Overview... 5 1.2 Feed Connectivity Requirements... 5 1.3 Symbol Ranges, Units, and Sequence Numbers... 7 1.4

More information

Version Updated: February 27, 2018

Version Updated: February 27, 2018 Version 1.64 Updated: February 27, 2018 Copyright 2018 Exchange LLC. All rights reserved. This document may not be modified, reproduced, or redistributed without the written permission of IEX Group, Inc.

More information

Turquoise. TQ401 - Level 2 MITCH UDP Market Data. Issue January 2018

Turquoise. TQ401 - Level 2 MITCH UDP Market Data. Issue January 2018 Turquoise TQ401 - Level 2 MITCH UDP Market Data Issue 3.5.3 03 January 2018 Contents 1.0 Introduction 4 1.1 Purpose 4 1.2 Readership 4 1.3 Document Series 4 1.4 Document History 6 1.5 Enquiries 11 6.0

More information

JSGCL TRADING TERMINAL. User Manual Getting Started

JSGCL TRADING TERMINAL. User Manual Getting Started JSGCL TRADING TERMINAL User Manual Getting Started Table of Contents 1 ABOUT THIS DOCUMENT... 5 1.1 Document Composition... 5 2 INTRODUCTION... 6 3 GETTING STARTED... 7 3.1 Login... 7 3.1.1 Login Window...

More information

Cboe Futures Exchange Multicast TOP Specification. Version 1.1.3

Cboe Futures Exchange Multicast TOP Specification. Version 1.1.3 Multicast TOP Specification Version 1.1.3 November 8, 2018 Contents 1 Introduction... 5 1.1 Overview... 5 1.2 Feed Hours and System Restart... 5 1.3 Feed Connectivity Requirements... 6 1.4 Symbol Ranges,

More information

MSRB RTRS Price Dissemination Services Specifications Document January 25, 2008 Version 2.6

MSRB RTRS Price Dissemination Services Specifications Document January 25, 2008 Version 2.6 MSRB RTRS Price Dissemination Services Specifications Document January 25, 2008 Version 2.6 The Municipal Securities Rulemaking Board began operating its Real-Time Transaction Reporting System on January

More information

Information Package on Shakedown Connectivity Test and Market Rehearsals

Information Package on Shakedown Connectivity Test and Market Rehearsals Information Package on Shakedown Connectivity Test and Market Rehearsals HKEx Orion Market Data Platform Securities Market & Index Datafeed Products (OMD-C) Version 1.0 31 May 2013 Contents CONTENTS 1.

More information

US Options Complex Multicast PITCH Specification

US Options Complex Multicast PITCH Specification Multicast PITCH Specification Version 2.1.0 November 16, 2018 Contents 1 Introduction... 6 1.1 Overview... 6 1.2 Complex Multicast PITCH Feed Descriptions... 6 1.3 Feed Connectivity Requirements... 6 1.4

More information

London Stock Exchange

London Stock Exchange London Stock Exchange MIT 303 Level 2 - MITCH Specification Issue 11.6 17 August 2015 Contents Disclaimer 4 1.0 Introduction 5 1.1 Purpose 5 1.2 Readership 5 1.3 Document Series 5 1.4 Document History

More information

BME Data Feed Compression Guidelines

BME Data Feed Compression Guidelines BME Data Feed Compression Document Name: BME Data Feed Compression Version: 1.0 Related to: BME Data Feed Release 5.5 Last update: 21-Oct-09 BME Data Feed Interface Specification Page 2 of 12 REVISION

More information

NFX GLIMPSE INTERFACE SPECIFICATIONS NFX GLIMPSE. Version 4.00

NFX GLIMPSE INTERFACE SPECIFICATIONS NFX GLIMPSE. Version 4.00 NFX GLIMPSE INTERFACE SPECIFICATIONS NFX GLIMPSE 1. Overview A complement to the NFX Depth of Market (NFX Depth) real-time data feed product, NFX GLIMPSE 4.0 is a point-to-point data feed connection that

More information

M I T 303 B I T - M I L L E N N I U M E X C H A N GE. MITCH Specification. Issue 6.7 October 2014

M I T 303 B I T - M I L L E N N I U M E X C H A N GE. MITCH Specification. Issue 6.7 October 2014 M I T 303 B I T - M I L L E N N I U M E X C H A N GE MITCH Specification Issue 6.7 October 2014 Contents MITCH Specification... 1 1 Introduction... 6 1.1 Purpose... 6 1.2 Readership... 6 1.3 Document series...

More information

REGISTRATION DATA INTERFACE SPECIFICATION

REGISTRATION DATA INTERFACE SPECIFICATION REGISTRATION DATA INTERFACE SPECIFICATION DEFINITIONS Data Transfer Catalogue DCC Status DCC Status File Electricity Registration Data Provider FTP FTPS Gas Registration Data Provider Hot Standby Router

More information

ArcaTrade Specification for Bonds

ArcaTrade Specification for Bonds Specification for Bonds For the New York Stock Exchange April 24, 2007 Version 1.07 Copyright 2006 Archipelago Holdings, Inc. All Rights Reserved. Copyright 2006 Archipelago Holdings, Inc. All rights reserved.

More information

SIX Flex delivers reference, market, regulation and tax data in easy-to-consume data files. Files are delivered on demand and/or on a regular basis.

SIX Flex delivers reference, market, regulation and tax data in easy-to-consume data files. Files are delivered on demand and/or on a regular basis. SIX Flex User Guide SIX Flex delivers reference, market, regulation and tax data in easy-to-consume data files. Files are delivered on demand and/or on a regular basis. This guide will show you the ins

More information

Table of Contents 1 AAA Overview AAA Configuration 2-1

Table of Contents 1 AAA Overview AAA Configuration 2-1 Table of Contents 1 AAA Overview 1-1 Introduction to AAA 1-1 Authentication 1-1 Authorization 1-1 Accounting 1-2 Introduction to ISP Domain 1-2 Introduction to AAA Services 1-2 Introduction to RADIUS 1-2

More information

Nasdaq ISE Trade Combo Feed Specification VERSION AUGUST 23, 2017

Nasdaq ISE Trade Combo Feed Specification VERSION AUGUST 23, 2017 Nasdaq ISE Trade Combo Feed Specification VERSION 1.0.1 AUGUST 23, 2017 Nasdaq ISE Trade Combo Feed Version 1.01 Nasdaq ISE Trade Combo Feed Table of Contents 1. Overview 3 2. Architecture 4 3. Data Types

More information

Specialized Quote Interface (SQF) VERSION 6.4N October 31, 2017

Specialized Quote Interface (SQF) VERSION 6.4N October 31, 2017 Specialized Quote Interface (SQF) VERSION 6.4N October 31, 2017 Nasdaq Options Market Nasdaq PHLX Nasdaq BX Options Specialized Quote Interface Version 6.4n Version 6.4n Page 1 Table of Contents 1 Overview...

More information

Using the Cable Monitor Tool

Using the Cable Monitor Tool APPENDIX B This appendix describes the Cisco ubr905 and Cisco ubr925 cable access routers Cable Monitor tool. The Cable Monitor is part of the router s onboard software that provides a web-based diagnostic

More information

Connectivity Specification Main Markets

Connectivity Specification Main Markets M I T 7 0 2 B I T M I L L E N N I U M E X C H A N G E Connectivity Specification Main Markets Issue 1.3 January 2015 1 Introduction... 4 1.1 Purpose... 4 1.2 Readership... 4 1.3 Document series... 4 1.4

More information

Japannext PTS OUCH Trading Specification for Equities

Japannext PTS OUCH Trading Specification for Equities Japannext PTS OUCH Trading Specification for Equities Version 1.8 Updated 8 November 2017 Table of Contents Introduction...3 Overview...3 Fault Redundancy...3 Service Configuration...3 Data Types...3 Inbound

More information

Forthnet Mobile Platform - groupsms http interface v1.0 1 / 9

Forthnet Mobile Platform - groupsms http interface v1.0 1 / 9 Table of Contents Introduction... 2 Requirements... 2 Connecting to Forthnet Mobile Platform... 2 Message submission... 3 Client Request... 3 Parameters... 4 Parameter user... 4 Parameter pass... 4 Parameter

More information

USER MANNUAL. Version 1.9.6

USER MANNUAL. Version 1.9.6 USER MANNUAL Version 1.9.6 Table of Contents 1. About this Document... 3 2. Manuscript Composition... 4 3. Getting Started... 4 3.1 BIPL Direct Login... 4 3.1.1 To log on to BIPL Direct... 5 3.1.2 Server

More information

BATS Chi-X Europe Multicast PITCH Specification

BATS Chi-X Europe Multicast PITCH Specification BATS Chi-X Europe Multicast PITCH Specification Version 6.7 8 June 2015 BATS Trading Limited is a Recognised Investment Exchange regulated by the Financial Conduct Authority. BATS Trading Limited is an

More information

Market Information Client System Manual

Market Information Client System Manual Market Information Client System Manual Ver. 3.0 Tokyo Stock Exchange, Inc Market Information Client System Manual 2 Table of Contents 1 About this Manual... 4 2 Flow of Procedures... 5 2.1 End-User License

More information

Cboe Futures Exchange Multicast Depth of Book (PITCH) Specification. Version

Cboe Futures Exchange Multicast Depth of Book (PITCH) Specification. Version Multicast Depth of Book (PITCH) Specification Version 1.0.14 February 21, 2018 Multicast PITCH Specification (Version 1.0.14) Contents 1 Introduction... 5 1.1 Overview... 5 1.2 Feed Hours and System Restart...

More information

ISE, GEMX & MRX Top Combo Quote Feed VERSION 1.0 AUGUST 23, 2017

ISE, GEMX & MRX Top Combo Quote Feed VERSION 1.0 AUGUST 23, 2017 ISE, GEMX & MRX Top Combo Quote Feed VERSION 1.0 AUGUST 23, 2017 Top Combo Quote Feed Version 1.0 Nasdaq ISE Top Combo Quote Feed Nasdaq ISE Glimpse for Top Combo Quote Feed Table of Contents 1. Overview

More information

Cboe Futures Exchange Multicast Depth of Book (PITCH) Specification. Version 1.1.5

Cboe Futures Exchange Multicast Depth of Book (PITCH) Specification. Version 1.1.5 Multicast Depth of Book (PITCH) Specification Version 1.1.5 November 8, 2018 Multicast PITCH Specification (Version 1.1.5) Contents 1 Introduction... 5 Overview... 5 Feed Hours and System Restart... 5

More information

Japannext PTS ITCH Market Data Specification for Equities

Japannext PTS ITCH Market Data Specification for Equities Japannext PTS ITCH Market Data Specification for Equities Version 1.5 Updated 26 October 2017 Table of Contents Introduction... 3 Overview... 3 Data Types... 3 Outbound Sequenced Messages... 3 Seconds

More information

2 Accessing Oracle Webmail

2 Accessing Oracle Webmail Oracle Collaboration Suite Using Oracle Webmail Release 2 (9.0.4.2) Part No. B10897-02 March 2004 You can use Oracle Webmail to: Compose and manage messages Create and manage message folders Manage public

More information

Table of Contents 1 AAA Overview AAA Configuration 2-1

Table of Contents 1 AAA Overview AAA Configuration 2-1 Table of Contents 1 AAA Overview 1-1 Introduction to AAA 1-1 Authentication 1-1 Authorization 1-1 Accounting 1-2 Introduction to ISP Domain 1-2 Introduction to AAA Services 1-3 Introduction to RADIUS 1-3

More information

DDE Client Driver PTC Inc. All Rights Reserved.

DDE Client Driver PTC Inc. All Rights Reserved. 2018 PTC Inc. All Rights Reserved. 2 Table of Contents DDE Client Driver 1 Table of Contents 2 DDE Client Driver 3 Overview 3 Driver Setup 4 Channel Properties General 4 Channel Properties Write Optimizations

More information

Cboe Europe Multicast PITCH Specification

Cboe Europe Multicast PITCH Specification Cboe Europe Multicast PITCH Specification Version 6.25 25 October 2018 Cboe Europe Limited is a Recognised Investment Exchange regulated by the Financial Conduct Authority. Cboe Europe Limited is an indirect

More information

Cboe Europe Multicast PITCH Specification

Cboe Europe Multicast PITCH Specification Cboe Europe Multicast PITCH Specification Version 6.22 26 January 2018 Cboe Europe Limited is a Recognised Investment Exchange regulated by the Financial Conduct Authority. Cboe Europe Limited is an indirect

More information

HF MEFFGate SIMULATION ENVIRONMENT GUIDE FOR THIRD PARTY TRADING APPLICATIONS AND MIFID II/MIFIR CONFORMANCE TESTING

HF MEFFGate SIMULATION ENVIRONMENT GUIDE FOR THIRD PARTY TRADING APPLICATIONS AND MIFID II/MIFIR CONFORMANCE TESTING HF MEFFGate SIMULATION ENVIRONMENT AND MIFID II/MIFIR CONFORMANCE TESTING GUIDE FOR THIRD PARTY TRADING APPLICATIONS Date: 26 th of September 2017 Version: 1.0 The information contained in this document

More information

BTS Trading Station. Quick Reference Guide Cash Markets

BTS Trading Station. Quick Reference Guide Cash Markets BTS Trading Station Quick Reference Guide Cash Markets Contents Quick Reference Guide 1.0 Getting Started 4 1.1 Application Layout 4 1.2 User Login and Password Management 4 1.3 Default Set Up 5 1.4 Virtual

More information

web po user guide Supplier

web po user guide Supplier web po user guide Supplier web po user guide table of contents supplier section 1 before you begin section 2 getting started and the basics section 3 Web PO Supplier Administration section 4 Viewing Purchase

More information

Cisco Instant Connect MIDlet Reference Guide

Cisco Instant Connect MIDlet Reference Guide Cisco Instant Connect MIDlet Reference Guide Cisco IPICS 4.7 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS

More information

Operation Manual AAA RADIUS HWTACACS H3C S5500-EI Series Ethernet Switches. Table of Contents

Operation Manual AAA RADIUS HWTACACS H3C S5500-EI Series Ethernet Switches. Table of Contents Table of Contents Table of Contents... 1-1 1.1 AAA/RADIUS/HWTACACS Over... 1-1 1.1.1 Introduction to AAA... 1-1 1.1.2 Introduction to RADIUS... 1-3 1.1.3 Introduction to HWTACACS... 1-9 1.1.4 Protocols

More information

Wide Area Network Device Presence Protocol (WAN DPP)

Wide Area Network Device Presence Protocol (WAN DPP) [MS-GRVWDPP]: Intellectual Property Rights Notice for Open Specifications Documentation Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages,

More information

ADT Frame Format Notes (Paul Suhler) ADI ADT Frame Format Proposal (Rod Wideman)

ADT Frame Format Notes (Paul Suhler) ADI ADT Frame Format Proposal (Rod Wideman) To: INCITS T10 Membership From: Paul Entzel, Quantum Date: 11 November 2002 Document: T10/02-329r2 Subject: Proposed frame format for ADT 1 Related Documents T10/02-233r0 T10/02-274r0 ADT Frame Format

More information

Borsa Italiana. MIT502 - Guide to Application Certification MIT502 - Guide to Application Certification. Issue 7.2 August 2017

Borsa Italiana. MIT502 - Guide to Application Certification MIT502 - Guide to Application Certification. Issue 7.2 August 2017 Borsa Italiana MIT502 - Guide to Application Certification MIT502 - Guide to Application Certification Issue 7.2 August 2017 ue 5.0 July 2015 Contents 1.0 Introduction 4 5.14 FIX Session Level Testing

More information

LINK Mobility SMS REST API MT and Delivery Reports Version 1.3; Last updated September 21, 2017

LINK Mobility SMS REST API MT and Delivery Reports Version 1.3; Last updated September 21, 2017 LINK Mobility SMS REST API MT and Delivery Reports Version 1.3; Last updated September 21, 2017 For help, contact support@linkmobility.com The most up-to-date version of this document is available at http://www.linkmobility.com/developers/

More information

REGISTRATION DATA INTERFACE SPECIFICATION

REGISTRATION DATA INTERFACE SPECIFICATION REGISTRATION DATA INTERFACE SPECIFICATION DEFINITIONS In this document, except where the context otherwise requires: expressions defined in section A of the Code (Definitions and Interpretation) have the

More information

Internet Engineering Task Force (IETF) Request for Comments: 8156 Category: Standards Track ISSN: June 2017

Internet Engineering Task Force (IETF) Request for Comments: 8156 Category: Standards Track ISSN: June 2017 Internet Engineering Task Force (IETF) Request for Comments: 8156 Category: Standards Track ISSN: 2070-1721 T. Mrugalski ISC K. Kinnear Cisco June 2017 DHCPv6 Failover Protocol Abstract DHCPv6 as defined

More information

Continuous Real Time Data Transfer with UDP/IP

Continuous Real Time Data Transfer with UDP/IP Continuous Real Time Data Transfer with UDP/IP 1 Emil Farkas and 2 Iuliu Szekely 1 Wiener Strasse 27 Leopoldsdorf I. M., A-2285, Austria, farkas_emil@yahoo.com 2 Transilvania University of Brasov, Eroilor

More information

NSEMD Feed Specification. Version: 6.0 Date: September 21, National Stock Exchange India Limited. All rights reserved.

NSEMD Feed Specification. Version: 6.0 Date: September 21, National Stock Exchange India Limited. All rights reserved. NSEMD Feed Specification Version: 6.0 Date: September 21, 2018 2013 National Stock Exchange India Limited. All rights reserved. Revision History Name Description Date Version 6.0 Inclusion of Commodity

More information

USA North 811. Positive Response System Requirements

USA North 811. Positive Response System Requirements USA North 811 Positive Response System Requirements Automated Response via TCP Connection Connect to posres.usanorth811.org (IP address 4.7.9.14) via TCP/7377 In the dialog below the (le arrow) means it

More information

General Remote Interface Description. en General Remote Interface Description

General Remote Interface Description. en General Remote Interface Description General Remote Interface Description en General Remote Interface Description General Remote Interface Description en 2 Table of Contents 1 Introduction...3 1.1 Purpose...3 1.2 Scope...3 1.3 Definitions,

More information

Japannext PTS GLIMPSE Market Data Specification for Equities

Japannext PTS GLIMPSE Market Data Specification for Equities Japannext PTS GLIMPSE Market Data Specification for Equities Version 1.2 Updated 26 October 2017 Table of Contents Introduction... 3 Overview... 3 Data Types... 3 Service Usage... 3 Outbound Sequenced

More information

NFX MARKET DATA FEED INTERFACE SPECIFICATIONS. NFX Market Data Feed

NFX MARKET DATA FEED INTERFACE SPECIFICATIONS. NFX Market Data Feed NFX Market Data Feed Table of Contents 1 INTRODUCTION... 3 1.1 PURPOSE... 3 1.2 ARCHITECTURE... 3 2 SESSION CHARACTERISTICS... 4 2.1 REAL-TIME PRODUCTION DATA... 4 2.2 PRE-LAUNCH TEST DATA... 4 2.3 TRANSMISSION

More information

Electronic Appraisal Delivery (EAD) Portal. FHA EAD General User Guide

Electronic Appraisal Delivery (EAD) Portal. FHA EAD General User Guide Electronic Appraisal Delivery (EAD) Portal FHA EAD General User Guide Last Updated: October 2015 FHA EAD General User Guide Page 2 of 87 Version 1.3.1 TABLE OF CONTENTS INTRODUCTION... 6 WHAT IS THE ELECTRONIC

More information

GSM GSM TECHNICAL May 1996 SPECIFICATION Version 5.0.0

GSM GSM TECHNICAL May 1996 SPECIFICATION Version 5.0.0 GSM GSM 04.63 TECHNICAL May 1996 SPECIFICATION Version 5.0.0 Source: ETSI TC-SMG Reference: TS/SMG-030463Q ICS: 33.060.50 Key words: Digital cellular telecommunications system, Global System for Mobile

More information

GENERAL INFORMATION ON BORSA İSTANBUL DATA DISSEMINATION INFRASTRUCTURE

GENERAL INFORMATION ON BORSA İSTANBUL DATA DISSEMINATION INFRASTRUCTURE GENERAL INFORMATION ON BORSA İSTANBUL DATA DISSEMINATION INFRASTRUCTURE Version: 1.0 CONTENTS 1 SCOPE AND AIM... 3 2 IT NETWORK ARCHITECTURE... 3 3 IMPORTANT ASPECTS ABOUT DATA DISSEMINATION TRAFFIC CHARACTERISTICS...

More information

Ethereal Exercise 2 (Part B): Link Control Protocol

Ethereal Exercise 2 (Part B): Link Control Protocol Course: Semester: ELE437 Introduction Ethereal Exercise 2 (Part B): Link Control Protocol In this half of Exercise 2, you will look through a more complete capture of a dial-up connection being established.

More information

SpaceWire-R DRAFT. SCDHA Issue September 2013

SpaceWire-R DRAFT. SCDHA Issue September 2013 SpaceWire-R DRAFT SCDHA 151-0.3 Issue 0.3 13 September 2013 Takahiro Yamada Japan Aerospace Exploration Agency (JAXA) Institute of Space and Astronautical Science (ISAS) 1 CONTENTS 1. INTRODUCTION... 3

More information

Transport Protocol (IEX-TP)

Transport Protocol (IEX-TP) Transport Protocol (IEX-TP) Please contact IEX Market Operations at 646.568.2330 or marketops@iextrading.com, or your IEX onboarding contact with any questions. Version: 1.1 Updated: December 22, 2014

More information

Mercateo Catalogue Management for Suppliers

Mercateo Catalogue Management for Suppliers The procurement platform for your business Quick Reference Guide Mercateo Catalogue Management for Suppliers Table of contents Login to the Mercateo Catalogue Management 2 Overview of the Catalogue Update

More information

RADIUS Configuration. Overview. Introduction to RADIUS. Client/Server Model

RADIUS Configuration. Overview. Introduction to RADIUS. Client/Server Model Table of Contents RADIUS Configuration 1 Overview 1 Introduction to RADIUS 1 Client/Server Model 1 Security and Authentication Mechanisms 2 Basic Message Exchange Process of RADIUS 2 RADIUS Packet Format

More information

People. Processes. Integrating Globally.

People. Processes. Integrating Globally. People. Processes. Integrating Globally. Course: isupplier for Suppliers Table of Contents Table of Contents Course Introduction...4 L1: Vendor Registration... 6 Register for isupplier using SteelTrack

More information

Introducing Cisco IPICS

Introducing Cisco IPICS CHAPTER1 The Cisco IP Interoperability and Collaboration System (Cisco IPICS) provides voice interoperability among disparate systems. It offers an IP standards-based solution that interconnects voice

More information

ISE, GEMX, & MRX Depth of Market Feed Specification VERSION 1.01 JUNE 13, 2017

ISE, GEMX, & MRX Depth of Market Feed Specification VERSION 1.01 JUNE 13, 2017 ISE, GEMX, & MRX Depth of Market Feed Specification VERSION 1.01 JUNE 13, 2017 Nasdaq ISE/Nasdaq GEMX/Nasdaq MRX Depth of Market Feed Nasdaq ISE/Nasdaq GEMX/Nasdaq MRX Glimpse for Depth of Market Feed

More information

[MS-RDPEMC]: Remote Desktop Protocol: Multiparty Virtual Channel Extension

[MS-RDPEMC]: Remote Desktop Protocol: Multiparty Virtual Channel Extension [MS-RDPEMC]: Remote Desktop Protocol: Multiparty Virtual Channel Extension Intellectual Property Rights Notice for Open Specifications Documentation Technical Documentation. Microsoft publishes Open Specifications

More information

Fixed Income Clearing Corporation MBS EPN IMPLEMENTATION GUIDE

Fixed Income Clearing Corporation MBS EPN IMPLEMENTATION GUIDE Fixed Income Clearing Corporation MBS EPN IMPLEMENTATION GUIDE Table of Contents 1. Introduction... 1 2. EPN Computer-to-Computer Interface (CTCI)... 2 2.1. General Information... 2 2.2. EPN Internal Processing...13

More information

Derivatives Market Data Feed Specifications (DMDF-UDP)

Derivatives Market Data Feed Specifications (DMDF-UDP) Derivatives Market Data Feed Specifications (DMDF-UDP) Created by: John Steinberg Updated by: Peshen Reddy Date: 2016-06-30 Version: 2.2 Derivatives Market Data Feed Specifications Page 1 / 43 TABLE OF

More information

UTP Snap-Shot 1.0 Version 1.0 Published October 2018

UTP Snap-Shot 1.0 Version 1.0 Published October 2018 UTP Snap-Shot 1.0 Version 1.0 Published October 2018 Table of Contents 1 Overview... 3 2 Architecture... 3 3 Data Types... 5 4 Message Formats... 6 4.1 Control Message... 7 4.2 Issue Symbol Directory Message

More information

e-lms Electronic Lodgement of Mailing Statements User Guide Version 4.5

e-lms Electronic Lodgement of Mailing Statements User Guide Version 4.5 e-lms Electronic Lodgement of Mailing Statements User Guide Version 4.5 Copyright Statement Copyright the Australian Postal Corporation 2016. All rights reserved. No part of this document may be reproduced,

More information

Please read this user guide to help you apply for Job Vacancies. Bookmark or download the guide for future use.

Please read this user guide to help you apply for Job Vacancies. Bookmark or download the guide for future use. Please read this user guide to help you apply for Job Vacancies. Bookmark or download the guide for future use. VACANCIES APPLICANT GUIDE INTRODUCTION This document is a User Guide to help you search and

More information

REGISTRATION DATA INTERFACE SPECIFICATION

REGISTRATION DATA INTERFACE SPECIFICATION REGISTRATION DATA INTERFACE SPECIFICATION DEFINITIONS Data Transfer Catalogue DCC Status DCC Status File Electricity Registration Data Provider Gas Registration Data Provider Hot Standby Router Protocol

More information

III Post Offices. Chapter 11, Creating a New Post Office, on page 143 Chapter 12, Managing Post Offices, on page 163.

III Post Offices. Chapter 11, Creating a New Post Office, on page 143 Chapter 12, Managing Post Offices, on page 163. III Post Offices Chapter 11, Creating a New Post Office, on page 143 Chapter 12, Managing Post Offices, on page 163 Post Offices 141 142 GroupWise 7 Administration Guide 11 Creating a New Post Office As

More information

INTERNATIONAL TELECOMMUNICATION UNION

INTERNATIONAL TELECOMMUNICATION UNION INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.774 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (06/97) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System. 7 Transaction capabilities

More information

Quote Using Orders (QUO) (Previously OTTO Version 1.4d)

Quote Using Orders (QUO) (Previously OTTO Version 1.4d) Quote Using Orders (QUO) (Previously OTTO Version 1.4d) Contents 1 Overview...2 1.1 Architecture...2 1.2 Data Types...3 1.3 Fault Redundancy...3 1.4 Service Bureau Configuration...4 1.5 Important Notes...4

More information

Dynamic Host Configuration (DHC) Internet-Draft Intended status: Standards Track Expires: August 31, 2017 February 27, 2017

Dynamic Host Configuration (DHC) Internet-Draft Intended status: Standards Track Expires: August 31, 2017 February 27, 2017 Dynamic Host Configuration (DHC) Internet-Draft Intended status: Standards Track Expires: August 31, 2017 T. Mrugalski ISC K. Kinnear Cisco February 27, 2017 DHCPv6 Failover Protocol draft-ietf-dhc-dhcpv6-failover-protocol-06

More information

User Manual SL-DD-Collect-1 v2.0.9 (with v2010)

User Manual SL-DD-Collect-1 v2.0.9 (with v2010) User Manual SL-DD-Collect-1 v2.0.9 (with v2010) Objective A means to collect money from customer accounts via the Sales Ledger in Sage 200 using Direct Debit mechanisms provided by BACS systems, in a similar

More information

Using the Belimo Cloud requires an Internet connection for creating and logging in to an account and accessing device data.

Using the Belimo Cloud requires an Internet connection for creating and logging in to an account and accessing device data. Belimo Cloud Manual Overview / Getting Started Welcome to the Belimo Cloud Thank you for deciding to use the Belimo Cloud. Now you'll be able to have centralized connection and management of compatible

More information

Request for Comments: 851 Obsoletes RFC: 802. The ARPANET 1822L Host Access Protocol RFC 851. Andrew G. Malis ARPANET Mail:

Request for Comments: 851 Obsoletes RFC: 802. The ARPANET 1822L Host Access Protocol RFC 851. Andrew G. Malis ARPANET Mail: Request for Comments: 851 Obsoletes RFC: 802 The ARPANET 1822L Host Access Protocol Andrew G. Malis ARPANET Mail: malis@bbn-unix Bolt Beranek and Newman Inc. 50 Moulton St. Cambridge, MA 02238 April 1983

More information

Test Guide 21 January Disaster Recovery Test Guide. 21 st January 2017

Test Guide 21 January Disaster Recovery Test Guide. 21 st January 2017 Test Guide Disaster Recovery Test Guide 21 st January 2017 1 Contents 1.0 Introduction 3 2.0 Test Overview 4 3.0 Before the test 5 4.0 Trading Date 6 5.0 Millennium IT platform 7 6.0 SOLA platform 8 6.1

More information

17 March r1 SAM-4 SAS-2 QUERY UNIT ATTENTION task management function

17 March r1 SAM-4 SAS-2 QUERY UNIT ATTENTION task management function To: T10 Technical Committee From: Rob Elliott, HP (elliott@hp.com) Date: 17 March 2007 Subject: 07-067r1 SAM-4 SAS-2 QUERY UNIT ATTENTION task management function Revision history Revision 0 (13 February

More information

03-186r3r3 SAS-1.1 Transport layer retries 25 October 2003

03-186r3r3 SAS-1.1 Transport layer retries 25 October 2003 To: T10 Technical Committee From: Rob Elliott, HP (elliott@hp.com) Date: 25 October 2003 Subject: 03-186r3r3 SAS-1.1 Transport layer retries Revision history Revision 0 (6 May 2003) first revision Revision

More information

Turquoise Equities Trading Gateway (NATIVE)

Turquoise Equities Trading Gateway (NATIVE) T Q 3 0 1 T E C H N I C A L S P E C I F I C A T I O N Turquoise Equities Trading Gateway (NATIVE) I S S U E 2.6 2 0 F e b r u a r y 2 0 1 3 1 Contents 1 INTRODUCTION... 5 1.1 Purpose... 5 1.2 Readership...

More information

Revision 6: Red text Incorporate comments from January 5, 2004 conference call. Minor wording changes.

Revision 6: Red text Incorporate comments from January 5, 2004 conference call. Minor wording changes. To: INCITS T10 Committee From: Susan Gray, Quantum Date: January, 5, 2004 Document Number: T10/03-355r6 Subject: ADT Section 4.7.1.3 1 Revision History Revision 6: Red text Incorporate comments from January

More information

US Equities TOP Specification. Version 1.3.1

US Equities TOP Specification. Version 1.3.1 US Equities TOP Specification Version 1.3.1 October 17, 2017 Contents 1 Introduction... 4 1.1 Overview... 4 1.2 Typography... 4 1.3 Data Types... 5 2 Protocol... 6 2.1 Message Format... 6 3 Sessions...

More information

MARKET FEED CM, FAO & CD TICK BY TICK FEED

MARKET FEED CM, FAO & CD TICK BY TICK FEED MARKET FEED CM, FAO & CD TICK BY TICK FEED Version: 5.5 Date: 12 August, 2015 NSE DATA & ANALYTICS LIMITED EXCHANGE PLAZA, PLOT NO. C/1, G BLOCK, BANDRA-KURLA COMPLEX, BANDRA (E), MUMBAI 400 051. INDIA.

More information

ITCH PROTOCOL SPECIFICATION DOCUMENT MARKET DATA

ITCH PROTOCOL SPECIFICATION DOCUMENT MARKET DATA ITCH PROTOCOL SPECIFICATION DOCUMENT MARKET DATA 1 REVISION HISTORY Version Last Updated Updates 1.0 June 23, 2015 Initial Version 1.1 July 14, 2015 Changes in condition in trade message as following:

More information

Contents. allpay Ltd Webconnect user guide V1.3

Contents. allpay Ltd Webconnect user guide V1.3 Contents 1 Introduction to Webconnect... 4 2 Technicalities... 4 2.1 Internet Security... 4 3 Support and Training... 4 3.1 allpay Support... 4 3.2 Training... 4 4 Accessing Webconnect... 4 4.1 Logging

More information

NZ Online Forms for Research Software Manual

NZ Online Forms for Research Software Manual NZ Online Forms for Research Software Manual Version 1.5 Released May 2016 2 P a g e N Z O n l i n e F o r m s f o r R e s e a r c h 1 INTRODUCTION... 6 2 GETTING STARTED... 6 2.1 Creating an Account...

More information

Stream Control Transmission Protocol

Stream Control Transmission Protocol Chapter 13 Stream Control Transmission Protocol Objectives Upon completion you will be able to: Be able to name and understand the services offered by SCTP Understand SCTP s flow and error control and

More information

e-frr SYSTEM USER GUIDE

e-frr SYSTEM USER GUIDE e-frr SYSTEM USER GUIDE for Electronic Submission of Financial Return Version 1.5 Jun 2015 Table of Contents 1. Introduction... 4 2. Background... 4 3. System Purpose... 4 4. Baseline Specification of

More information

[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions

[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions [MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions Intellectual Property Rights Notice for Open Specifications Documentation Technical Documentation. Microsoft publishes Open

More information

Kea Messages Manual. Kea Messages Manual

Kea Messages Manual. Kea Messages Manual Kea Messages Manual i Kea Messages Manual Kea Messages Manual ii Copyright 2011-2018 Internet Systems Consortium, Inc. ("ISC") Kea Messages Manual iii Contents 1 Introduction 1 2 Kea Log Messages 2 2.1

More information

Trusted Advisor User Guide. inty CASCADE v 2.9.0

Trusted Advisor User Guide. inty CASCADE v 2.9.0 Trusted Advisor User Guide inty CASCADE v 2.9.0 Table of Contents 1. Overview... 2 2. Logging in to inty CASCADE... 2 2.1 Forgotten Password... 4 2.2 Password Complexity... 5 3. Home Page... 7 4. Navigation...

More information

IBM Content Manager for iseries. Messages and Codes. Version 5.1 SC

IBM Content Manager for iseries. Messages and Codes. Version 5.1 SC IBM Content Manager for iseries Messages and Codes Version 5.1 SC27-1137-00 IBM Content Manager for iseries Messages and Codes Version 5.1 SC27-1137-00 Note Before using this information and the product

More information

Backup App v7. Quick Start Guide for Windows

Backup App v7. Quick Start Guide for Windows Backup App v7 Quick Start Guide for Windows Revision History Date Descriptions Type of modification 30 Jun 2016 First Draft New 25 Nov 2016 Added Restore Options to Ch 8 Restore Data; Combined Technical

More information

Revisions. General. T10 Membership FROM: Paul A. Suhler, Quantum Corporation DATE: 29 May 2008 SUBJECT: T10/07-469r4, ADT-2: Internet ADT (iadt)

Revisions. General. T10 Membership FROM: Paul A. Suhler, Quantum Corporation DATE: 29 May 2008 SUBJECT: T10/07-469r4, ADT-2: Internet ADT (iadt) TO: T10 Membership FROM: Paul A. Suhler, Quantum Corporation DATE: 29 May 2008 SUBJECT: T10/07-469r4, -2: Internet (i) Revisions 0 Initial revision (2 November 2007) 1 First revision (9 March 2008) Changed

More information