IDACS/NCIC 2000 Remote System Message Example Supplement and FAQ's
Remote System Interface to OpenFox
Message Structure and Examples
This attachment is to be used as a supplement to the documents:
1) State of Indiana, Implementation Specifics for Use of DMPP-2020, Trusted Server Interface, and
2) DMPP2020 Abbreviated Guide
This document is NOT intended as an all encompassing example dictionary of every single message in the system. The NCIC and NLETS manuals must be used to construct the message from the Message Key to the end.
FAQ'S - See bottom of this page for Frequently Asked Question Section.
Input Message Header:
TDAC Trusted Destination Access Code, eight character value supplied by ISP IDACS.
Period .
REFERENCE User reference field, ten alphanumeric character value. Equivalent to the legacy ENT field. User supplied data, that will be returned on automated responses.
Period .
USERID User Identification field, four to fifteen alphanumeric character value. Equivalent to the legacy OID field. User supplied data. Must match what has been entered into OpenFox user database. Agency must supply list of values ahead of production implementation.
Period .
Message Text NCIC 2000 or NLETS message text beginning with the Message Key. Consult the NCIC and NLETS manauls for proper message structure. Systems are encouraged to implement field edits in accordance with standards to lower the reject rate, allowing fewer rejects, valid messages, thus quicker response times.
Registration by License Plate:
TDAC.REFERENCE.USERID.MKE.ORI.DESTINATION.CONTROL.LIC.LIY.LIT
Example:
ISPM0000.2655.DSMITH.RQ.INISP5202.IN.*2655000000.LIC/32T4712.LIY/2002.LIT/PC
Registration by SOC in the OLN field (This is how it's referred to by CPI OpenFox):
NOTE: THIS MESSAGE IS ONLY VALID FOR 'IN'. NLETS equivalent is a RNQ, and uses NAM and DOB.
TDAC.REFERENCE.USERID.MKE.ORI.DESTINATION.CONTROL.OLN
Example:
ISPM0000.2655.DSMITH.LQ.INISP5202.IN.*TEST000000.OLN/S123456789
Registration by VIN:
TDAC.REFERENCE.USERID.MKE.ORI.DESTINATION.CONTROL.VIN.VMA
Example:
ISPM0000.2655.DSMITH.RQ.INISP5202.IN.*2655000000.VIN/123456J654321.VMA/CHEV
Title by VIN:
NOTE: THIS MESSAGE IS ONLY VALID FOR 'IN'. NLETS has no equivalent for Title checks in other states.
TDAC.REFERENCE.USERID.MKE.ORI.DESTINATION.CONTROL.VIN.VMA
Example:
ISPM0000.2655.DSMITH.LQ.INISP5202.IN.*2655000000.VIN/123456J654321.VMA/CHEV
Drivers License by NAM, DOB and SEX:
TDAC.REFERENCE.USERID.MKE.ORI.DESTINATION.CONTROL.NAM.DOB.SEX
Example:
ISPM0000.2655.DSMITH.DQ.INISP5202.IN.*2655000000.NAM/TEST,TEST.DOB/19510408.SEX/M
By NAM and OLN:
TDAC.REFERENCE.USERID.MKE.ORI.DESTINATION.CONTROL.NAM.OLN
Example:
ISPM0000.2655.DSMITH.DQ.INISP5202.IN.*2655000000.NAM/TEST,TEST.OLN/S123456789
By NAM and SOC:
TDAC.REFERENCE.USERID.MKE.ORI.DESTINATION.CONTROL.NAM.SOC
Example:
ISPM0000.2655.DSMITH.DQ.INISP5202.IN.*2655000000.NAM/TEST,TEST.SOC/123456789
Article Stolen Check by TYP and SER:
TDAC.REFERENCE.USERID.MKE.ORI.TYP.SER
Example:
ISPM0000.2655.DSMITH.QA.INISP5202.TYP/YTEST.SER/TEST08112003
Gun Stolen Check (by SER, MAK, CAL) MAK and CAL optional, but will reduce number of hits:
TDAC.REFERENCE.USERID.MKE.ORI.SER.MAK.CAL
Example:
ISPM0000.2655.DSMITH.QG.INISP5202.SER/TEST12345.MAK/SW.CAL/38
Boat Stolen Check by REG:
TDAC.REFERENCE.USERID.MKE.ORI.REG
Example:
ISPM0000.2655.DSMITH.QB.INISP5202.REG/IN1234AB
By BHN:
Example:
ISPM0000.2655.DSMITH.QB.INISP5202.BHN/TESTBHN12345
Person Check for Wanted, Missing, Protective Order, Sex Offender, etc. by NAM, DOB, SEX, RAC:
TDAC.REFERENCE.USERID.MKE.ORI.NAM.DOB.SEX.RAC
Example:
ISPM0000.2655.DSMITH.QW.INISP5202.NAM/LAST,FIRST INITIAL.DOB/12311953.SEX/M.RAC/W
Or by Additional Identifiers, SOC, OLN
ISPM0000.2655.DSMITH.QW.INISP5202.NAM/LAST,FIRST INITIAL.SOC/123456789.OLN/S123456789
Response Messages Format:
TDAC Trusted Destination Access Code, eight character value supplied by ISP IDACS.
Period
REFERENCE User reference field, ten alphanumeric character value. Equivalent to the legacy ENT field. User supplied data, that will be returned on automated responses.
Period
Message Text NCIC 2000 or NLETS message text beginning with the Message Key. Consult the NCIC and NLETS manauls for proper message structure. Systems are encouraged to implement field edits in accordance with standards to lower the reject rate, allowing fewer rejects, valid messages, thus quicker response times.
NOTE: ASCII {0A} is used for new line.
Example:
ISPM0000.*1000000000.{0A}
TXT{0A}
orig ori - INISP0097{0A}
1L0100TW,MRI7567332{0A}
INISP0097{0A}
NO RECORD LIC/652ZGM LIS/MA{0A}{0A}
MRI 7567333 IN: NCIC 14416 AT 08SEP2003 13:38:12{0A}
OUT: SPT9 7 AT 17SEP2003 15:06:03
FAQ's - Frequently Asked Questions Section.
Q. Does the State assign a static IP address for the remote servers that interface to IDACS?
A. A static IP address will be assigned to the server by the IHETS/ITN Network Group at the time the router is installed.
Q. What is the IP Address and TCP port that OpenFox expects the application to connect to and exchange message traffic?
A. The OpenFox server is at 10.17.253.100:6800
Q. In the RQ and DQ examples above, what is the CONTROL field, the one with the asterist?
A. This is an NLETS field that should contain the contents of what was put in the REFERENCE field. The format must be as seen in the example. Begin with an asterist and zero filled to 10 characters. NLETS will return this value on responses.
Q. We have heard various dates and timelines for proposed cutover plans and time limits for the changeover process, and are curious as to what is involved in setting ourselves up to be allowed to test with IDACS, so that we can get approved, and begin the roll out of our customer sites, and what the current time lines for rollover are?
A. FBI CJIS Security Policy requires 3-des encryption between the remove system and IDACS 2000/NCIC 2000. The first agency that attempted to set this up, uncovered a CISCO VPN Crypto Tunnel problem. This problem is being researched by Indiana DoIT with Cisco. As of 11/3/2003, there is no projected fix date. Also, the agency using your system must keep IDACS informed on progress of the interface, etc. Because of this, and also because we have 50+ agencies with systems to convert, the agency that is using your system needs to work with Andre Clark and/or Mike Dearinger, to schedule work properly.
Q. Is there any relationship between the validation field in the Extended Header of a response compared to the original request? By response, I do not mean the protocol level acknowledgement, I mean the data message containing the application response to the functional request?
A. No, there is no relationship between the Validation Field of the DMPP2020 Extended Message Header and any data contained in the application response data. OpenFox returns the Validation Field in the DMPP2020 protocol header of the response exactly as it is sent by the originating system. The Validation field is for the originating system's use in any way it sees fit. One common use may be to tie responses to their original request for purposes of message tracing or auditing.
Q. At the current time, our CAD system is not programmed to handle binary objects. Does the interface need to recognize DSEO-2020 objects (and presumably throw them away), or can IDACS be configured not to send binary objects to systems that cannot process them?
A. To the best of my knowledge, the image indicator field, "IND/", defaults to "IND/N" (return NO images on response) at this time. When our CAD is image-capable, images can be requested with responses by the inclusion of the message field code "IND/Y". Images should rationally not be expected on unsolicited messages.
Q. The header containing a "TDAC" and user ID (I'll call it a "TDAC Header") appears to be optional and intended for remote workstation interfaces. Since our CAD will employ a single interface to its CAD system, is the TDAC header required? (Let's answer this question first. If the answer is yes, then I will have more questions.)
A. Assuming you are referring to the above header structure, The TDAC header is the mandatory application preface to ALL request messages. The header serves two primary functions, one for OpenFox and one for the originating system.
First, the TDAC code and USERID represent the originating system and user to OpenFox for authority verification purposes. Without these fields, OpenFox cannot verify the authority of the agency or the certification of the individual user within the agency to receive the data requested.
The TDAC code will be defined by IDACS administrative staff and will be unique to the originating system. PLEASE NOTE that the TDAC represents your entire system, NOT INDIVIDUAL DEVICES DOWNSTREAM. Because of this, the REFERENCE field is REQUIRED FOR ALL TRANSACTIONS. See below for more information about this.
The USERID is also assigned by IDACS staff, and is unique to the INDIVIDUAL USER using your system. GENERIC USERIDS WILL NOT BE ASSIGNED FOR ANY REASON. A list of ALL individuals using your system must be submitted to the IDACS staff, along with certain identifying information. (Please have your client agency contact the IDACS Section at (317) 232-8292 for more details on what information is required for EACH individual user.)
The second function served by the TDAC header is for the benefit of the originating system. As mentioned above, the TDAC field represents the entire originating system, NOT individual devices downstream from it. Therefore, the REFERENCE field is the ONLY way OpenFox has of identifying the specific device behind the originating system. This is not really important to OpenFox, per se, but without the REFERENCE field, which is returned in all responses to a given request, the originating system has NO way to properly route the response back to the original downstream device. This is no different than the current legacy implementation of the ENT field, which was provided for precisely the same purpose.
Q. With regard to the USERID field: You state that the "Agency must supply list of values" but then you go on to say that "The USERID is also assigned by IDACS staff." Does that mean that the agency supplies a list of people and IDACS supplies the actual USERID code values, or can the agency suggest code values?
A. The agency must submit a list of persons authorized and certified to use the system (commonly known as "certified operators"), to include their name and a challenge question/response (for password reset purposes.) If our CAD system has assigned user ids for these individuals, they may be included in the submitted information; however, the agency must understand that if the preferred user id is already in use in the OpenFox system, an alternate user id will be assigned by the IDACS Section staff.
Q. If IDACS assigns the codes, then I presume that our CAD will need to convert their users over to the new code values, or else we'll need to provide some kind of conversion table. If IDACS does assign the code values, can you tell me what size they will be? You said the USERID is "four to fifteen" characters. I presume it would actually be somewhere in between. The CAD system currently accomodates six.
A. The user id is four to fifteen characters, typically comprised of the user's first initial and full last name, to the limits of the user id field. A request to limit the user id to only six characters would need to discussed with the IDACS Section staff.
Q. How much lead time should my agency expect will be needed to get their users registered with IDACS?
A. As the IDACS Section is responsible for entering user ids, they will need to provide this information. In general, of course, the amount of lead time will depend upon the number of users and the date upon which they are needed. The IDACS Section can be reached at (317) 232-8292.
Q. Is there a test server that we will be able to connect to from a test CAD system in order to verify that we have correctly programmed to the DMPP-2020 and OpenFox standards?
A. Unfortunately, there is no test system available. As such you will be testing against the live system with live data.
Q. Will unique ORI's need to be be assigned to each mobile data client?
A. No. A single ORI will be assigned to the mobile system as a whole. Each message sent to OpenFox from the mobile system must use that one ORI.
Q. In the legacy system, when I sent a "QVR", I would get back not only the BMV response, but NCIC and NLETS also. Now I only get the BMV response. Do I need to send separate transactions to get the IDACS and NCIC responses?
A. The message key "QVR" is an internal message key in the new system, not intended for use by agencies. To get a full range of responses on a BMV inquiry, use the standard NLETS message keys of "RQ" for license plates and "DQ" for driver licenses. Boats registrations can be queried using a "BQ" transaction to get both the boat registration and any stolen boat information available from NCIC or IDACS. Check the NLETS Users' Guide for details on formatting the requests.
Q. What about firearm registrations, are they available?
A. No. The IDACS system does not yet have the ability to return firearm registration data. Only stolen and recovered gun information from IDACS and NCIC is available. However, you can inquire on other states' Concealed Weapons Permit systems using the "CWQ" message key. Check the NLETS Users' Guide for details on formatting the request.
- How do I obtain an Indiana Juvenile or Adult Criminal History Record?
- Does Indiana honor an out-of-state gun permit?
- How long is a criminal history record kept in the Indiana State Police database?
- What is legal age for operating a moped?
- How long does a new resident to Indiana have before required to purchase Indiana...
- Who should I contact when I have a complaint against an Indiana State Police emp...
