Table of Contents - APTAStandards.com
Table of Contents - APTAStandards.com Table of Contents - APTAStandards.com
Field # Field Name Description that is sending the message. This may be used for return routing through a gateway 7 Receiver’s Device ID A unique number within a system that identifies the device. This may be used for routing through a gateway. When messages are used in a broadcast (instead of a device-to-device connection), this field is empty 8 Routing Information The type of this field is unspecified. It shall be used to further direct intermediate sites how to deliver the message to its final destination. An example usage would be the channel number of a device in a multi-drop connection 9 Version The Vending Equipment Interface Specification Version. The value shall be “1.1" 10 Response Needed Needed True if the sender expects a response or acknowledgment. False if not. Always false for broadcasts Message Body: The message body consists of three or four fields depending on the type of the dialogue being utilized. The details of the message body are further evaluated in the following sections. 4.4.4 Message Types VEI defines six dialog classes with several services provided by each. A dialog class is a grouping of functionally similar services, which are fulfilled by sending and receiving a set of messages. The table in Exhibit 4.4-3 describes the six dialog classes offered by VEI. Exhibit 4.4-3 Dialog Classes Dialogue Description Condition A particular circumstance or situation at a device Variable Access Access, by name, data items that are resident on the device Log Files Historic record of events and other archived information that can be used to determine a sequence of events at the device File Management Allows remote access to file systems Transaction Support use of credit/debit cards as a payment medium at the vending equipment Program Execution Action or set of actions to be carried out by the device 4.4.4.1 Transaction Data Condition dialogues are best suited for Transaction Data messages proposed by WP4. A condition dialogue is used to report a particular circumstance, or a situation at a device, such as an intrusion alarm, a component failure, or a sale of a product. Accompanying attributes might include for example the time of day, the value of products sold, or the method of payment. The structure of the condition dialogue is contained in Exhibit 4.4-4. Page 42
Exhibit 4.4-4 Condition Dialogue Structure Field Description of Field/Attributes 1 Message Header 2 Condition Attributes 3 Additional Attributes By incorporating the relevant Additional Attributes (Full list of attributes can be found in Chapter 17 of the specification), the conditional dialogue can be configured to accommodate the Farecard Usage and Add Value Transactions as proposed by WP4. 4.4.4.2 Card Management Data Variable access dialogue can be utilized for Financial Audit Data and Negative List messages. Variable access dialogues are related to accessing, by name, data items that are resident on the device. A variable is a data item that can assume any one of a set of values. The Variable Access dialogue structure is illustrated in Exhibit 4.4-5. Exhibit 4.4-5 Variable Access Dialogue Structure Field Description of Field/Attributes 1 Message Header 2 List of Variable Names 3 Variable Value List By adding the relevant Variables indicated in the field three of the message (Full list of variables can be found in Chapter 17 of the specification), the Variable dialogue can be configured to accommodate the Negative List and Financial Audit Data messages as proposed by WP4. File management dialogues allow remote access to file systems on the devices and are structured as illustrated in Exhibit 4.4-6. Exhibit 4.4-6 File Management Dialogue Structure Field Description of Field/Attributes 1 Message Header 2 File Transfer Direction 3 File Name 4 File Attributes The File Management dialogue can be formatted to accommodate certain WP4 Card Management Data and System and Device Data messages (Appendix B). This can be achieved by incorporating the appropriate File Attributes (Full list of attributes can be found in Chapter 17 of the specification) into the dialogue. Page 43
- Page 1 and 2: SMART CARD STANDARDS AND SPECIFICAT
- Page 3 and 4: 4.4.7 Security Requirements........
- Page 5 and 6: Document History Revision Reason Fo
- Page 7 and 8: Acronym List UTFS Universal Transit
- Page 9 and 10: technology to achieve interoperabil
- Page 11 and 12: This report encompasse s the review
- Page 13 and 14: Identify S m art Card Indust ry S t
- Page 15 and 16: The standards and specifications th
- Page 17 and 18: These standards and specifications
- Page 19 and 20: Although there is no “one-to-one
- Page 21 and 22: 4.1.4.2 Card Management Data The st
- Page 23 and 24: with ISO/IEC 7816-6, there is no re
- Page 25 and 26: these messages constitutes a file.
- Page 27 and 28: Phone interviews and/or email corre
- Page 29 and 30: The ITSO message body consists of i
- Page 31 and 32: Exhibit 4.2-2 Product Types Type Co
- Page 33 and 34: Capability Values or RFU Product Pr
- Page 35 and 36: opted to contract these services ou
- Page 37 and 38: e given careful consideration for a
- Page 39 and 40: - Transaction date and time - Trans
- Page 41 and 42: cardholder related data as in the c
- Page 43 and 44: CLIENT Exhibit 4.3-9 OFX Security S
- Page 45: may well be eliminated if, and when
- Page 49 and 50: 4.4.7 Security Requirements The Mes
- Page 51 and 52: Application Retailer Product Retail
- Page 53 and 54: Exhibit 4.6-1 CID Edge Interface Me
- Page 55 and 56: 4.6.8 Timing and Routing The CID Ed
- Page 57 and 58: 4.7.4.1 Transaction Data The “Far
- Page 59 and 60: 4.7.4.3 System and Device Data The
- Page 61 and 62: Following the authentication proces
- Page 63 and 64: Data” transaction messages propos
- Page 65 and 66: Field Name Description reading the
- Page 67 and 68: 4.8-7 Product Transactions Usage Me
- Page 69 and 70: 4.8.4.5 Peer-to-Peer Clearing and S
- Page 71 and 72: standard does not mandate the compl
- Page 73 and 74: Item Number Exhibit 4.9-2 Part 1 Fi
- Page 75 and 76: 4.9.4.2 PICC Scheme Control Message
- Page 77 and 78: • Registration • Negative List
- Page 79 and 80: 5.0 FINDINGS This section presents
- Page 81 and 82: Exhibit 5-2 illustrates the relevan
- Page 83 and 84: Required. This set of specification
- Page 85 and 86: Project/Specification/Standard Spon
- Page 87 and 88: APPENDIX B COMPLETED CRITERIA FORMS
- Page 89 and 90: ISO/IEC 8583 Criteria Transaction D
- Page 91 and 92: TRANSLINK ® Criteria Transaction D
- Page 93 and 94: RIS PART 4 Criteria Transaction Dat
- Page 95 and 96: ITSO DATA ELEMENTS Message Type Dat
Field # Field Name Description<br />
that is sending the message. This may be used for return<br />
routing through a gateway<br />
7 Receiver’s Device ID A unique number within a system that identifies the<br />
device. This may be used for routing through a gateway.<br />
When messages are used in a broadcast (instead <strong>of</strong> a<br />
device-to-device connection), this field is empty<br />
8 Routing Information The type <strong>of</strong> this field is unspecified. It shall be used to<br />
further direct intermediate sites how to deliver the message<br />
to its final destination. An example<br />
usage would be the<br />
channel number <strong>of</strong> a device in a multi-drop<br />
connection<br />
9 Version The Vending Equipment Interface<br />
Specification Version.<br />
The value shall be “1.1"<br />
10 Response Needed Needed True if the sender<br />
expects a response or<br />
acknowledgment. False if not. Always false for broadcasts<br />
Message<br />
Body:<br />
The message body consists <strong>of</strong> three or four fields depending on the type <strong>of</strong> the dialogue<br />
being utilized. The details <strong>of</strong> the message body are further evaluated in the following<br />
sections.<br />
4.4.4 Message Types<br />
VEI<br />
defines six dialog classes with several services provided by each. A dialog class<br />
is a<br />
grouping <strong>of</strong> functionally similar services, which are fulfilled by sending and receiving a<br />
set<br />
<strong>of</strong> messages. The table in Exhibit 4.4-3 describes the six<br />
dialog classes <strong>of</strong>fered by<br />
VEI.<br />
Exhibit 4.4-3 Dialog Classes<br />
Dialogue Description<br />
Condition A particular circumstance or situation at a device<br />
Variable Access Access, by name, data items that are resident on the device<br />
Log Files Historic record <strong>of</strong> events and other archived information that can be used to<br />
determine a sequence <strong>of</strong> events at the device<br />
File Management Allows remote access to file systems<br />
Transaction Support use<br />
<strong>of</strong> credit/debit cards as a payment medium at the vending<br />
equipment<br />
Program Execution Action or set <strong>of</strong> actions to be carried out by the device<br />
4.4.4.1 Transaction Data<br />
Condition dialogues are best suited for Transaction Data messages proposed by WP4.<br />
A condition dialogue is used to report a particular circumstance, or a situation at a<br />
device, such as an intrusion alarm, a <strong>com</strong>ponent failure, or a sale <strong>of</strong> a product.<br />
Ac<strong>com</strong>panying attributes might include for example the time <strong>of</strong> day, the value <strong>of</strong><br />
products<br />
sold, or the method <strong>of</strong> payment. The structure <strong>of</strong> the condition dialogue is<br />
contained<br />
in Exhibit 4.4-4.<br />
Page 42
Change language