MCHS Tenprint Interface Control Document (ICD)

Mississippi Department of Public Safety

Criminal Information Center

MCHS Tenprint

Interface Control Document (ICD)

Version 5.02 R36

updated

December 31, 2019

TABLE OF CONTENTS

1.0 SCOPE ............................................................................................................................................... 1

2.0 REFERENCES ................................................................................................................................... 2

3.0 OVERVIEW OF SCANNING STATION INTERFACE WITH MCHS ................................................. 3

4.0 SCANNING STATION AND INTERFACE REQUIREMENTS........................................................... 4

4.1 TENPRINT TRANSACTIONS – TYPES OF AGENCIES AND TYPES OF SUBMISSIONS .................................. 4 4.2 TRANSACTION RESPONSE MESSAGES ................................................................................................ 6 4.3 ADMINISTRATIVE MESSAGES ............................................................................................................. 7

5.0 SCANNING STATION CONFIGURATIONS ..................................................................................... 9

5.1 CONFIGURATION OPTIONS ................................................................................................................. 9 5.1.1 Configuration 1 ..................................................................................................................................... 9 5.1.2 Configuration 2 ..................................................................................................................................... 9 5.1.3 Configuration 3 ................................................................................................................................... 10

5.2 INSTALLATION CHECKLIST................................................................................................................ 11

6.0 SUBMITTING CERTIFICATION TEST TRANSACTIONS .............................................................. 13

7.0 IDENTIFYING MESSAGES RECEIVED FROM MCHS .................................................................. 14

8.0 PRINT RESPONSES FROM MCHS ON SCANNING STATION PRINTER REQUIREMENTS ..... 15

9.0 PRINT TENPRINT AND PALM PRINT CARD AT SCANNING STATION REQUIREMENTS ....... 16

10.0 STORE, RETRIEVE, RESUBMIT TRANSACTION ON SCANNING STATION REQUIREMENTS 17

11.0 SECURITY REQUIREMENTS ..................................................................................................... 18

12.0 CIC CERTIFICATION REQUIREMENTS FOR SCANNING STATIONS .................................... 19

APPENDIX A CONTENT OF EACH RECORD TYPE IN A TRANSACTION ...................................... 20

A.1 TYPE 1 TRANSACTION INFORMATION RECORD .................................................................................. 21 A.2 TYPE 2 TENPRINT DATA RECORD .................................................................................................... 25 A.3 TYPE 4 HIGH-RESOLUTION GRAYSCALE FINGERPRINT IMAGE RECORD .............................................. 37 A.4 TYPE 10 FACIAL AND SMT IMAGE RECORD (FUTURE) ....................................................................... 41 A.5 TYPE 15 VARIABLE-RESOLUTION PALM PRINT IMAGE RECORD .......................................................... 57 A.6 ANNOTATIONS FOR FINGERPRINTS IN FIELD 2.084 AND FOR PALM PRINTS IN FIELD 15.018 ................ 67

APPENDIX B ANSI/NIST TRANSACTION FORMAT .......................................................................... 68

B.1 TAGGED TEXT RECORD FORMAT ..................................................................................................... 69 B.2 TAGGED TEXT WITH BINARY RECORD FORMAT ................................................................................. 70 B.3 BINARY RECORD FORMAT ............................................................................................................... 70 B.4 IDC FIELD VALUES.......................................................................................................................... 70

APPENDIX C TRANSACTIONS SENT BY A SCANNING STATION TO MCHS ............................... 71

C.1 SMTPS MAIL PROCESSING REQUIREMENTS .................................................................................... 71 C.2 LEGACY SMTP MAIL PROCESSING .................................................................................................. 73

APPENDIX D RESPONSES FROM MCHS TO A SCANNING STATION ........................................... 74

D.1 POP3S MAIL PROCESSING REQUIREMENTS .................................................................................... 74 D.2 LEGACY POP3 MAIL PROCESSING................................................................................................... 75 D.3 MS SEARCH RESPONSE, PROSECUTOR AND COURT DISPOSITION FORMS, DNA DATABASE

COLLECTION FORM, AND RECORD UNDER REVIEW NOTICE ......................................................................... 76 D.4 MCHS REJECT NOTICE .................................................................................................................. 80

D.5 MCHS WARNING NOTICE................................................................................................................ 84 D.6 FBI SEARCH RESPONSE AND FBI ERROR RESPONSE ....................................................................... 85

APPENDIX E ADMIN MESSAGES FROM MCHS TO A SCANNING STATION ................................ 90

E.1 EDIT TABLE DOWNLOAD MESSAGES ................................................................................................ 91 E.2 ATN BLOCK MESSAGES .................................................................................................................. 94

APPENDIX F ATN CHECK DIGIT ALGORITHM ................................................................................ 97

APPENDIX G SAMPLE TRANSACTIONS WITH TYPE 1, 2, AND 4 RECORDS ............................. 101

G.1 ARREST TRANSACTION .................................................................................................................. 102 G.1.1 ARR Transaction Field Contents ...................................................................................................... 102 G.1.2 ARR Non-Binary Field Format ......................................................................................................... 106 G.1.3 ARR MIME Email Message Format ................................................................................................. 107

G.2 APPLICANT TRANSACTION ............................................................................................................. 108 G.2.1 APP Transaction Field Contents ....................................................................................................... 108 G.2.2 APP Non-Binary Field Format ......................................................................................................... 112 G.2.3 APP Email Message MIME Format ................................................................................................. 113

G.3 DOC INMATE RECEIPT TRANSACTION ............................................................................................ 114 G.3.1 DOC Transaction Field Contents ...................................................................................................... 114 G.3.2 DOC Non-Binary Field Format ........................................................................................................ 117 G.3.3 DOC MIME Email Message Format ................................................................................................ 118

APPENDIX H SAMPLE TYPE 10 AND TYPE 15 RECORDS ........................................................... 119

H.1 TYPE 10 FACIAL AND SMT IMAGE RECORDS (FUTURE) ................................................................... 120 H.1.1 Type 10 Record Field Contents .......................................................................................................... 120 H.1.2 Type 10 Record Non-Binary Field Format ........................................................................................ 125

H.2 TYPE 15 PALM PRINT IMAGE RECORD ............................................................................................ 126 H.2.1 Type 15 Record Field Contents .......................................................................................................... 126 H.2.2 Type 15 Record Non-Binary Field Format ........................................................................................ 128

APPENDIX I CARD SAMPLES ............................................................................................................ 129

I.1 MISSISSIPPI STATE ARREST CARD ................................................................................................. 130 I.2 FBI APPLICANT CARD ................................................................................................................... 132 I.3 FBI PALM PRINT CARD FD-884 ..................................................................................................... 133

CHANGE LOG

Date Version Change

April 15, 2003 5.00 (New document)

June 20, 2003 5.01 Field 1.02 Format Version Number: Value changed to "0501"

Field 1.08 Arrest/Applicant/DOC Agency ORI: In Appendix A, for ARRs, the source of the value corrected and made consistent with other references in the document.

Field 1.08 Arrest/Applicant/DOC Agency ORI: In Appendix A, for DOCs, the edit table was changed.

Field 2.014 FBI #: Field deleted.

Field 2.015 SID #: Field deleted.

Field 2.018 Name: In Appendix A, valid character set modified.

Field 2.020 Place of Birth: In Appendix A, edit table is changed.

Field 2.037 Reason Fingerprinted: In Appendix A, source corrected to be consistent with Section 4.1.

Field 2.084 Amputated and Bandaged: In Appendix A, field type and occurrences corrected and made consistent with other references in the document.

Field 2.705 Arrest Charge Set/Citation: In Appendix A, underscore removed from edit table name.

Field 2.706 Fee Paid: In Appendix A, Source clarified to indicate that this field applies only to Billable Applicant and No Charge Applicant Resubmit Applicant submissions.

Transaction Samples: In Appendix G, value for finger positions 11-14 in Impression Type field and value for plain thumbs in hll field corrected.

August 6, 2003 5.02 Field 1.02 Format Version Number: Value changed to "0502". Updated samples in Appendix G to reflect the new version number.

Field 1.09 Transaction Control No: Added hyphens between elements of the TCN format.

Field 1.11 Native Scanning Res: Changed length to 5.

Field 1.12 Nominal Transmitting Res: Changed length to 5.

Removed requirements for Type 7 records including reference to TIFF specification, modifications to Section 4.1, A.1, and Appendix B introduction. Removed Section A.4 and renumbered A.5 to A.4.

October 6, 2003 5.02 Installation checklist: Added naming conventions for station and operator ids. Added step to update Hosts table. Added step to coordinate software and data entry configuration options.

Field 1.08 Arrest/Applicant/DOC Agency ORI length changed to Maximum 9.

Field 1.09 Transaction Control No value description updated to include the CERT- transactions described in Section 6.

Field 2.020 Place of Birth changed to be required for all types of transactions.

Field 2.027 Height and Field 2.029 Weight changed to be required.

Field 2.084 other requirements revised to allow both Amputated or Bandaged code and Type 4 image for the same finger if the scanning station is a cardscan. (Prescreening will delete the Type 4 image if both are found for the same finger.)

Made miscellaneous wording clarifications throughout the document. Changed the term "hardcoded-default" to "pre-set default". The definition and requirement are unchanged.

March 17, 2004 5.02 Fields 1.07 Print Agency and 1.08 Arrest/Applicant/DOC Agency ORI Source and Value requirements clarified.

Appendix D TCN added to Rap Sheet document samples.

Appendix E.2 clarified to indicate that the ATN Block message applies only to livescans.

No requirements have been changed.

November 30, 2004 5.02 Correct typos.

February 25, 2005 5.02 Corrected types and made miscellaneous wording clarifications.

Resequenced the steps in the Installation Checklist in Section 5.2.

No requirements have been changed.

July 13, 2006 5.02 Increase size of Originating Agency Case Number to 20 per FBI in EFTS 7.1.

Date Version Change

December 18, 2006 5.02 Change document name "Prosecutor Intake Form" to "Prosecutor Disposition Form". Add new document "Court Disposition Form".

Update Installation Checklist to reflect elimination of Hosts table and changes in Users table.

Eliminate optional scanning station configuration C.

Modify Type 4 Impression Type field requirements when a Store and Forward is used.

Correct Enforce Agency 'Used with' in list of Edit Tables.

Add step 18 in the Installation Checklist regarding submitting test transactions when a new station is first installed.

July 11, 2008 5.02 Update document references and ATN Block Message discussion.

October 15, 2009 5.02 Update Type 4 Image Scanning Resolution field values consistent with the ANSI/NIST standard.

Add Nickname cross-field edit.

Change minimum value for Date of Birth and add cross-field edits.

Add basic date edits relative to current date.

Miscellaneous clarifications.

November 22, 2010 5.02 Miscellaneous clarifications.

October 28, 2011 5.02 Add Type 10 for facial and SMT images to all tenprint transactions. Appendices A.4, B, D.4, and H.

Add Type 15 for palm print images to all tenprint transactions. Appendices A.5, B, D.4, and H.

Miscellaneous clarifications.

March 6, 2012 5.02 Add new fields to Type 10 and Type 15 per ANSI/NIST-ITL 1-2011. Not distributed.

April 9, 2012 5.02 Minor updates to new Type 10 and Type 15 fields per ANSI/NIST-ITL 1-2011. Not distributed.

June 7, 2013 5.02 Revise use of Amputated and Bandaged field in Type 2 record to be consistent with FBI EBTS specification.

Add requirement to communicate with MCHS over SSL/TLS secure connection (see Appendices C and D).

January 31, 2014 5.02 Miscellaneous clarifications.

August 11, 2014 5.02 Type 2: Changed SSN validation: SSNs beginning with 9 are now allowed.

Type 15: Corrected field 15.018 max occurs.

Type 15: Revised to allow APP transactions for specified reasons fingerprinted.

September 2, 2014 5.02 Type 2: Changed SSN validation::SSN 123456789 is now allowed.

Type 2: Changed DOB validation: DOB 13 years before Date Printed, DOA, or DOO is now allowed and must be allowed.

Type 15: Writer's palm is required.

Type 15: Clarification that palm positions must be captured in accordance with the FBI's "Guidelines for Capturing Palmprints and Supplementals", available on FBI biospecs.org website and that the full palm position and the upper palm position must include all fingers including the distals.

September 29, 2014 5.02 Added Sex Offender Registration (APP for OR) to Types of Agencies/Types of Submissions table in Section 4.1and Palm Print Appendix A.5 ; add Sex Offender Reg to field 2.037 Reason Fingerprinted.

Updated reference to FBI Palm Print Capture documentation.

December 5, 2014 5.02 R18 Indicated only full palms are accepted from cardscans and added instructions for printing cards of upper/lower palm pairs.

February 11, 2015 5.02 R19 Added new EBTS v. 10.0 fields to FBI Response samples.

July 31, 2015 5.02 R20 Clarifications.

November 4, 2015 5.02 R21 Added DNA Form sample

November 18, 2016 5.02 R22 n/a

Date Version Change

February 28, 2017 5.02 R23 Clarifications. Some of the clarifications include:

- Enhanced explanation of ATN Block Messages and how scanning stations are to process them in Appendix E.2,

- Added Record Under Review message to Section 7 and Appendix D.

- Enhanced explanation of requirements for recording partial amputations, full amputations, and otherwise unprintable fingerprint and palm print positions, and use of Fields 2.084 and 15.018.

- Enhanced explanation of messages to explain that they must be printed (and displayed) using fixed-font in order to achieve the alignment shown in the sample responses.

Removed SMTP and POP3 protocols. Only SMTPS and POP3S are allowed.

Removed requirements for CIC operator-submitted transactions.

All cross-field validations are mandatory for new certifications.

Incorporated requirements that were previously documented separately:

- Scanners and WSQ algorithm must be FBI-certified.

- Additional requirements for printing MCHS and FBI responses. (Section 8)

- Additional requirements for printing fingerprint and palm print card images. (Sec 9)

- Additional requirements for storing transactions. (Section 10)

- Requirement regarding VPN-IPSEC. (Section 11)

- Sequence of fields on cardscans to accommodate efficient data entry. (Appx A.2)

- Additional requirements for Edit Table Download messages. (Appendix E.1)

Added validation for Field 2.022 Date of Birth: Cannot be more than 99 years before Transaction Date with exception that 19000101 must be allowed.

Modified requirement for Fields 10.004 and 15.004 Source Agency ORI must be populated with the same value as 1.07 Print Agency ORI.

Updated Installation Checklist.

March 31, 2017 5.02 R24 Changed allowed characters for 2.709 DOC Number: Only alphabetic and numeric characters are allowed.

Removed requirement to notify scanning station operator when station begins using Next ATN Block.

Changed requirement for palm prints on cardscan: Allow either full palms or upper/lower pairs but PREFER that a cardscan support BOTH.

April 18, 2017 5.02 R25 Corrected entries in table in Sec 4.1: Reason Fingerprinted for No Charge Applicant Resubmit does not need to be the same as reason fingerprinted in original Billable Applicant transaction. (As specified in Appendix A.2.)

Clarified that, for livescans, for the ORI in field 1.07 Print Agency ORI, the value is assigned to the livescan by the CIC.

Changed Source options for Field 1.08 for Instate Inquiry Only APP transactions from CIC stations: Can be either user-entered or hardcoded - agency-specific. CIC will specify at time of installation.

May 9, 2017 5.02 R26 Clarified requirements for subfields of Employment and Residence fields.

Clarified email To and From lines in email messages both ways between the scanning station and MCHS.

June 30, 2017 5.02 R27 Updated requirements for deleting messages from a scanning station's POP3 mail file. Vendor's software must automatically remove a scanning station's mail messages from its POP3 mail file on the server, preferably after it is retrieved, but not more than a maximum number of days specified by the CIC.

July 31, 2017 5.02 R28 Added requirement for Driver's License. It is required if reason fingerprinted is 'CDL-Hazmat'. This has been the requirement since CDL Hazmat stations were set up but was not previously documented in ICD.

August 1, 2017 5.02 R29 Clarified cross-field validation on Date of Birth for validation with Date of Offense and Arrest Type.

September 30, 2017 5.02 R30 Max size of an image in a Type 15 record increased to accommodate some large images of full palm prints.

March 30, 2018 5.02 R31 Minor wording clarifications including Section 12 and Appendix B.1.

February 15, 2019 5.02 R32 Removed CDL-HazMat related requirements for Driver's License.

Minor wording clarifications.

Date Version Change

July 1, 2019 5.02 R33 Update examples of Reject Notices.

Add requirements for legacy stations using SMTP and POP3 mail processing.

September15, 2019 5.02 R34 Revised 2.022 Date of Birth validation, for APPs, with regard to Date Printed. Changed to only apply to APP for SOR transactions. Does not apply to any other type of APP.

Minor wording clarifications.

October 25, 2019 5.02 R35 Numerous clarifications.

December 31, 2019 5.02 R36 Numerous clarifications. Updated Configuration Options. Updated Installation Checklist.

December 31, 2019 Tenprint ICD Ver. 5.02 Rev. 36 1

1.0 SCOPE

This document provides the requirements for tenprint livescans and cardscans to interface with the Mississippi Criminal History System (MCHS).

MCHS is operated by the Mississippi Department of Public Safety Criminal Information Center (hereafter referred to as the CIC) located in Pearl, Mississippi. The CIC may be reached by telephone at (601) 933-2600.

The document is structured as follows.

Section 2 References lists referenced documents that provide additional detail or background for the interface.

Section 3 Interface Overview provides a high level overview of the data flows between the fingerprint scanning station and the MCHS system.

Section 4 Interface Requirements presents detailed requirements for building and sending transactions to MCHS. It also describes the format and processing requirements of responses and administrative messages MCHS sends to a scanning station. This section refers to additional requirements in the appendices.

Section 5 Scanning Station Configurations describes allowable options for configuring multiple scanning stations at one location and provides an installation checklist for installation of scanning stations at local agencies or the CIC.

Section 6 Submitting Test Transactions describes how a vendor can submit test transactions. Section 7 Identifying Messages from MCHS provides guidance on how to identify messages sent

from MCHS to the scanning station. Section 8 Printing Responses from MCHS on Scanning Stations describes requirements for

printing all responses from MCHS on the scanning station printer. Section 9 Printing Tenprint and Palm Print card Image Requirements describes the requirements

for printing card images on the scanning station printer. Section 10 Store, Retrieve and Resubmit Transactions describes the requirements for storing and

subsequently resubmitting transactions on a scanning station Section 11 Security Requirements identifies the security requirements.

Sections 4 through 11 states the requirements for interfacing with MCHS and these requirements must be met in their entirety. Section 4 references Appendices A through H that include requirements that must be completely met. The reference documents in Section 2 provide more detail and may be referenced in the requirements sections.

This document includes requirements for Type 10 records for facial images and Type 10 records for SMT images. However, TYPE 10 RECORDS for either facial images or SMT images ARE NOT CURRENTLY ALLOWED. Vendors will be notified, in the future, when they can begin scheduling certification testing for submitting Type 10 records for facial images (aka mugshots).


2.0 REFERENCES

The following references contain requirements for MCHS.

1. Data Format for the Interchange of Fingerprint, Facial & Other Biometric Information, American National Standards Institute (ANSI/NIST-ITL 1-2011) (referred to in this document as the 'ANSI/NIST transmission format' or 'NIST-2011').

2. JPEG File Interchange Format (JFIF), Version 1.02, September 1992, available at

http://www.jpeg.org/public/jfif.pdf.

3. SMTP Service Extension for Secure SMTP over Transport Layer Security, Request for Comment (RFC) 3207, February 2002.

4. Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols, RFC 7817m March 2016.

5. Internet Message Format, RFC 2822, April 2001.

6. Post Office Protocol - Version 3, RFC 1939, May 1996.

7. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, November 1996.

8. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, RFC 2046, November 1996.

9. MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text, RFC 2047, November 1996.

10. MCHS Security Policy, version in effect at time of certification.

11. Instructions for Sample Transactions to Submit to CIC for Pre-Certification Review.

12. MCHS Tenprint Scanning Station Certification Test Procedures, version in effect at time of certification.

13. MCHS Palm Print Submission Certification Test Procedures, version in effect at time of certification.

14. MCHS Reject Notice and Warning Notice Error Messages.

15. A Practical Guide for Palm Print Capture, available on fbibiospecs.org website.

The following reference provides background information. It does not contain requirements for

transactions sent to MCHS. The MCHS system transforms data from MCHS formats to EBTS formats as needed. MCHS does not accept FBI EFTS or EBTS transaction data formats.

16. Electronic Biometric Transmission Specification (EBTS), US Department of Justice (DOJ), Federal Bureau of Investigation (FBI), Criminal Justice Information Services (CJIS) Division, Version 10..0, September 30, 2017.


3.0 OVERVIEW OF SCANNING STATION INTERFACE WITH MCHS

This brief overview of the data flows provides a context for understanding the detailed interface requirements.

The diagram above shows the flow of information between a fingerprint scanning station (livescan or cardscan) and MCHS. The primary flow consists of a scanning station sending applicant (APP), arrest (ARR), or Department of Corrections (DOC) tenprint transactions (labeled (1) in the diagram) to MCHS and then receiving Mississippi Transaction Responses (labeled (2) in the diagram) and FBI Transaction Responses (labeled (3) in the diagram).

A tenprint transaction (1) must include a set of rolled and plain tenprints. In some cases, it may include Palm Prints, and in the future, in some cases, it may include facial images.

A Mississippi Transaction Response (2) may be one or more of the following: a Search Response, Prosecutor and Court Disposition Forms, a DNA Database Collection Form, or a Reject Notice. A Search Response will be either a State rap sheet or an indication that no record exists for the subject (for APP transactions only). Prosecutor and Court Disposition Forms are sent at the same time as Mississippi Search Responses for an ARR. Under certain conditions, a DNA Database Collection Form will accompany Mississippi Search Responses for an ARR. MCHS sends a Reject Notice back to a scanning station if there are uncorrectable errors in the transaction content or fingerprint quality errors are detected.

Likewise, an FBI Transaction Response (3) will be either: a Search Response or an Error Response. A Search Response will be either an FBI search result containing the subject's FBI rap sheet or an indication the subject is not known to the FBI. The FBI may instead respond with an Error Response if, for example, the quality of the submitted tenprints is too low to be usable. MCHS forwards FBI responses back to the scanning station.

The remaining two data flows shown in the diagram above are administrative messages. The Edit Table Download (labeled (4) in the diagram) provides tables of valid values that are used to validate data entry fields. Edit Table Download messages are sent to initialize the valid value lists on a scanning station when a station first begins operation and subsequently when the edit tables change. Typically, this occurs one or more times per month.

The last flow, labeled (5), provides pre-assigned numeric ranges for arrest tracking numbers (ATNs). These are used by a livescan station in each arrest transaction. The message is sent to initialize a scanning station when the station first begins operation and subsequently when all of the ATNs in the previously assigned block have been used and another block is needed. How often this occurs depends on how many arrest transactions the station sends and how large a block is assigned.

MCHS

Repository

Fingerprint

Scanning

Station

APP, ARR, or DOC Transaction (1)

Mississippi Transaction Response (2)

FBI Transaction Response (3)

Edit Table Download (4)

ATN Block (5)


4.0 SCANNING STATION AND INTERFACE REQUIREMENTS

This section describes requirements for all transactions that a scanning station sends to the MCHS system and all messages MCHS sends to a scanning station. Details of these requirements are documented in Appendices A through H.

Section 4.1 identifies the tenprint transactions that may be sent from a scanning station to MCHS and describes their content. The messages sent from MCHS to a station are identified in Sections 4.2 and 4.3.

4.1 Tenprint Transactions – Types of Agencies and Types of Submissions

The MCHS processes tenprint transactions for law enforcement agencies, civil applicant agencies, and the Department of Corrections. A scanning station will support multiple types of submissions for an agency depending on the type of agency that operates the scanning station and what other agencies it supports. The types of submissions required for each type of agency are as follows:

Law Enforcement agency: A scanning station must support the following types of submissions: Arrest when a subject is arrested and booked, non-billable Law Enforcement Applicant background check, Criminal Inquiry Only background check, and Sex Offender Registration (APP for SOR) (Sheriff's Offices only).

Also, a law enforcement agency may support a Civil Applicant agency. If so, a single scanning station will be required to support submissions for both types of agency.

Civil Applicant agency: A scanning station must support the following types of submissions: Billable Applicant transaction for background checks and resubmission of an applicant transaction as a No Charge Applicant Resubmit.

A No Charge Applicant Resubmit is used if the FBI/NGI rejects a billable transaction because the prints are not legible. In this case, the FBI allows the transaction to be corrected and resubmitted without additional charge.

Department of Corrections: A scanning station must support the following types of submissions: DOC inmate intake when an inmate arrives for incarceration, non-billable Law Enforcement Applicant background check, and Sex Offender Registrations (APP for SOR).

Criminal Information Center: A scanning station at the CIC must support the following types of submissions: all of the types of submissions described above and one additional type of background check - the Instate Inquiry Only.

Also, a scanning station at the CIC must be able to be set up as a special purpose station that will be allowed to submit only a specified subset of these types of submissions.

Each type of submission uses one of the three types of tenprint transactions (ARR, APP, and DOC). The type of submission is identified by the values of some key fields. The table on the following page shows the types of submissions grouped by type of agency and the required value of these key fields.

A scanning station must be set up so that an operator first identifies the type of submission. Then, based on this table, the scanning station prompts the operator for only the applicable fields and hardcodes field values when there is only one possible value.


Type of Submission

1.04 Type of Transaction

1.08 Arrest/Applicant /DOC Agency ORI

1.10 Transaction Control Ref No

2.037 Reason Fingerprinted

Law Enforcement Agency

Arrest ARR ORI of agency that made the arrest (same value as in field 2.702)

-- --

Law Enforcement Applicant

APP ORI of agency that requested the background check

-- 'Law Enforcement'

Criminal Inquiry Only APP ORI of agency that requested the inquiry

-- 'CRIMINAL INQUIRY'

For Sheriff's Offices only:

APP for SOR (for Sex Offender Registration)

APP ORI of Sheriff's Office agency that processed the Sex Offender Registration

-- 'Sex Offender Reg'

Civil Applicant Agency

Billable Applicant APP ORI of agency that requested the background check

-- From a predefined list of reasons (Reason Fingerprinted edit table)

No Charge Applicant Resubmit


Transaction Control No from FBI's Error Response

From a predefined list of reasons (Reason Fingerprinted edit table)

Department of Corrections

Inmate Intake DOC ORI of agency that processed the inmate intake

-- --





APP ORI of agency that processed the Sex Offender Registration


Criminal Information Center

Arrest ARR ORI of agency that made the arrest

-- --




Criminal Inquiry Only APP ORI of agency that requested the inquiry

-- 'CRIMINAL INQUIRY'

Instate Inquiry Only APP ORI of agency that requested the inquiry

or CIC ORI

-- 'Instate Inquiry Only'

Billable Applicant APP ORI of agency that requested the background check

-- From a predefined list of reasons (Reason Fingerprinted edit table)



Transaction Control No from FBI's Error Response

From a predefined list of reasons (Reason Fingerprinted edit table)


APP ORI of Sheriff's Office or DOC agency that processed the Sex Offender Registration


Inmate Intake DOC ORI of agency where the inmate will reside

-- --


Note for cardscans: An agency may use an arrest card for a Criminal Inquiry Only request, but the cardscan must generate an APP transaction.

The MCHS tenprint ARR, APP, and DOC transaction formats follow the ANSI/NIST transmission format. The following record types must be present in each transaction:

Type 1 Transaction Information Record

Type 2 Tenprint Data Record

Type 4 High-Resolution Grayscale Fingerprint Image Record

The following record types are allowed and optional in some tenprint transactions:

Type 10 Facial Image Record (future)

Type 10 SMT Image Record (future)

Type 15 Variable-resolution Palm Print Image Record

Appendix A.4 and A.5 indicates which types of transaction (TOTs) may include Type 10 Facial, Type 10 SMT and Type 15 records as of the date of this document. Type 10 Facial, Type 10 SMT and Type 15 records will be allowed in additional TOTs in the future.

The appendices in this document provide details on how to build ARR, APP, and DOC transactions:

Appendix A provides detailed requirements for each field in each type of record in a tenprint transaction. Note that the field source, value and other requirements may depend on type of transaction (ARR, APP, DOC), the type of agency where the scanning station is installed (a local agency, Dept. of Corrections, or the CIC), the type of submission (e.g., Billable Applicant), and the type of scanning station (livescan or cardscan).

Appendix B, along with the ANSI/NIST-ITL 1-2011 transmission format, provides details on how to properly format an overall transaction file and each record within the file. Appendix B specifies the MCHS implementation of the ANSI/NIST standard. Appendix B provides a detailed explanation of how to use the separators in various types of tagged fields.

Appendix C describes, in detail, how to package the transaction in an email message using SMTPS.

Appendix G provides samples of an ARR, an APP, and a DOC transaction. These provide samples of the formats described in Appendices A and B.

Appendix H provides samples of Type 10 Facial and SMT records and Type 15 Palm Print records.

4.2 Transaction Response Messages

In response to a tenprint transaction, a scanning station will receive one or more transaction response messages, via email, to be printed on a printer attached to the scanning station. Some responses will be sent within minutes while others may take up to 24 hours. Each is sent as soon as it is available. At the time of installation, the agency will specify whether these responses should be sent to the printer automatically or sent to an email inbox.

There are five types of transaction response messages. When a transaction is successfully processed, MCHS generates an in-state MS Search Response (containing a rap sheet or a no record response) and, for APPs, MS Prosecutor and Court Forms.

MCHS validates the format and data content of a tenprint transaction. If uncorrectable errors occur, the transaction is not processed and a MCHS Reject Notice is sent to the scanning station. An objective of this process is to provide notification as soon as possible and often while the subject is still available, so that the transaction can be resubmitted.

Most arrest transactions, all Applicant transactions (with the exception of Instate Inquiry Only), and all DOC transactions are sent to the FBI's NGI. The FBI generates either an FBI Search Response (containing


a rap sheet or a no record response) or an FBI Error Response in response to these transactions. MCHS forwards them to the scanning station.

The transaction response messages that are sent depend on the type of submission as shown in the table below.

Type of Submission Transaction Response Messages

Arrest MS Search Response, Prosecutor and Court Disposition Forms, and under certain conditions, DNA Database Collection Form - or - MCHS Reject Notice

FBI Search Response - or - FBI Error Response

MS Warning Notice (only if warning messages are generated)

MCHS Record Under Review Notice (occasionally)


MS Search Response - or - MCHS Reject Notice



Criminal Inquiry Only MS Search Response - or - MCHS Reject Notice








Billable Applicant MS Search Response - or - MCHS Reject Notice







DOC MS Search Response - or - MCHS Reject Notice




Instate Inquiry Only MS Search Response - or - MCHS Reject Notice


Appendix D.1 describes how a transaction response message is packaged in an email message.

Appendix D.3 describes the MCHS-generated search responses, disposition forms, DNA forms, and review notice.

Appendix D.4 describes the MCHS-generated reject notice and Appendix D.5 describes the MCHS-generated warning notice.

Appendix D.6 describes the two responses generated by the FBI.

Section 7 explains how each message can be identified.

4.3 Administrative Messages

There are two types of administrative messages.

Edit Table Download Messages: For many fields, the value must be selected from a pre-determined list of valid values. These lists are defined by the CIC and are periodically downloaded to the scanning stations since the values in some tables change. The valid value lists on the scanning station must be automatically updated without human intervention.

Appendix E.1 describes the content of the Edit Table Download message. The appendix describes how this table is packaged in an email message, and provides a sample of this message. Section 7 explains how this message can be identified for proper processing.


ATN Block Messages: Arrest Tracking Numbers (ATNs) provide a unique identifier each time a subject is arrested. ATNs are preprinted on the Arrest tenprint cards and are entered by the scanning station operator on a cardscan. However, livescans must generate the ATN when a tenprint transaction is created. The numbers are controlled by the CIC and assigned to a livescan in blocks. The assigned numbers are sent to a livescan in an ATN Block message.

Appendix E.2 describes the content of the message. The appendix describes how this message is packaged in an email message, and provides a sample of this message. Section 7 explains how this message can be identified for proper processing.

Appendix F gives the algorithm a livescan station must use to compute the check digit that must be appended to an ATN.


5.0 SCANNING STATION CONFIGURATIONS

5.1 Configuration Options

5.1.1 Configuration 1

The most common configuration is a single scanning station - either a livescan or a cardscan - that connects directly to MCHS and has one type of scanner device connected to it. In this configuration, a scanning station sends transactions to MCHS according to the specifications identified in Section 4.1 and receives responses from MCHS according to Section 4.2. The scanning station also handles the administrative messages described in Section 4.3.

This configuration is shown in the diagram below.


Another configuration is similar to Configuration 1 with a single scanning station, but has two types of scanner devices attached - one for scanning cards and another for obtaining live scans of a person's prints. In other words, the single scanning station serves as both a livescan and a cardscan.

This second configuration is shown in the diagram below.

Some requirements in this document are unique to one type of scanning station or another. The single scanning station is responsible for ensuring that all transactions it submits to MCHS (Section 4.1) are compliant with the ICD requirements for each type of scanner device and for handling responses and administrative messages (Sections 4.2 and 4.3).

MCHS Scanning Station 1

Tenprint Transactions

Tenprint Responses

and Admin Messages

MCHS Scanning Station 2


Tenprint Responses

and Admin Messages

Card Scanner Device

Live Scanner Device



A third configuration is shown in the diagram below. It connects two or more scanning stations (shown as Scanning Stations 2 and 3) to MCHS through a concentrator (also known as a Store and Forward system). In this case, MCHS only interfaces with the concentrator that is connected to MCHS as if it is a single scanning station. The concentrator forwards all transactions to MCHS (Section 4.1) and receives all responses and administrative messages (Sections 4.2 and 4.3). All transactions sent to MCHS from the concentrator are associated with the station id of the concentrator.

In this configuration, the concentrator is responsible for receiving transactions sent from scanning stations 3 and 4 and sending them to MCHS. Each scanning station has one scanner device attached to it. The concentrator is also responsible for routing all responses from MCHS to the scanning station that generated the corresponding transaction (or to some other appropriate destination).

The concentrator is also responsible properly distributing all administrative messages. It is responsible for ensuring that edit table downloads are distributed to all attached scanning stations. The concentrator must manage the use of Arrest Tracking Numbers by the livescan stations. The ATN provides a key linkage for a single arrest throughout the criminal justice process. How this occurs is not important to MCHS as long as the ATNs belong to the assigned ranges and multiple scanning stations never generate the same ATN.

Finally, the concentrator vendor is responsible for ensuring that all transactions it submits to MCHS are compliant with the ICD requirements from whatever type of attached scanning station created the transaction.

MCHS Concentrator

Scanning Station 3

Scanning Station 4


Tenprint Responses

and Admin Messages


Tenprint Responses

and Admin Messages


Tenprint Responses

and Admin Messages


5.2 Installation Checklist

The following checklist summarizes the items that will need to be coordinated between the CIC, the scanning station vendor, and the local agency or MDOC after certification and prior to deploying a scanning station.

Item Responsible Party Action

1 Vendor Vendor: Must send a notice to the CIC not less than 10 days prior to any installation at a customer site.

If requested by the CIC, also provide a schematic of the system to be installed with an explanation detailing any changes from the configuration used by the vendor in the certification process. The CIC will review the installed configuration. Refer to Section 5.0 regarding configuration options.

Specify:

type(s) of scanning station(s)

type(s) of scanners( tenprint or palm print and card scanner or live scanner) make and model of scanners.

concentrator (if applicable)

printer(s)

connections to other systems

physical location(s)

2 Scanning Station Vendor, Local Agency, and CIC

CIC: If schematic was requested, approve schematic of the system to be installed. If there are any changes from the certified configuration, the local agency site may not operate in a live mode until the CIC approves the configuration.

3 Scanning Station Vendor and CIC

All parties: Determine the agency type/ types of submissions the station will be allowed to submit (refer to Section 4.1).

All parties: Determine whether livescan will be allowed to submit Type 15 palm print records.

CIC: Compare agency type/types of submission with those that were certified. If applicable, verify that palm print submission was certified. Compare make/model of scanners with those that were certified.


Ensure that all security requirements are met (see Section 11.)


All parties: Determine the correct values for all fields with a possible source of 'hardcoded - agency-specific' or 'pre-set default' to ensure that they are valid and correct. If there is a choice of which way to set up the field, determine which way is appropriate for the local agency.

This includes:

1.07 Print Agency ORI

1.08 Applicant Agency ORI

1.08 DOC Agency ORI (if certified for DOC TOTs)

2.067 Image Capture Equipment including Equipment Make and Equipment Model

2.702 Arrest Agency ORI

(Requirements for these fields are in Appendix A.)

All parties: Determine the response routing requirements.

6 CIC and Scanning Station Vendor

CIC: Assign an IP address.

CIC: Assign a Station Id. Scanning station ids must use the following naming conventions. The first two characters must be selected from the following:

ls - local agency livescan station lc - local agency cardscan station cs - CIC livescan station cc - CIC cardscan station Vendor: Configure scanning station. Use the station id in the Transaction Control Number, as the from_station/operator_id in the email From line, and to log into the station's POP3 mail account.


Item Responsible Party Action

7 CIC Set up scanning station record.

Set up agency record including print routing flags.

Set up POP3 mail file for the scanning station.

For a livescan, set up ATN blocks.

Update authorization tables.

8 CIC and Scanning Station Vendor

CIC: Send Edit Table Download and ATN Block messages to the new stations.

Vendor: Ensure that Edit Table Download and ATN Block messages are received and properly processed.

9 Scanning Station Vendor in coordination with CIC

Vendor: Submit test transactions for each type of transaction that will be supported by this scanning station. The CIC will provide instructions on how to submit test transactions.

CIC: Review test transactions. Verify that validations that should be detected by the scanning station are not appearing in Reject Notices.

CIC: Verify that Format Version Number is '0502'.

CIC: Notify the vendor of transaction format problems that are in addition to those that appear on the Reject Notice.

CIC: Verify that the station id in the TCN and the station id in the email From line are the same.

10 CIC Approve installed system before scanning station operates in a production mode.


If palm prints are to be submitted, conduct Palm Print certification part 2 (see Palm Print Submission Certification Test Procedures document).


6.0 SUBMITTING CERTIFICATION TEST TRANSACTIONS

For purposes of certification testing, a scanning station must be capable of submitting transactions with a special format in the Transaction Control No (TCN) field.

To indicate that a transaction is a certification test transaction, the following format for the TCN must be supported.

CERT-<CIC-station_id>-<descriptive_name>

where:

- the first 5 characters must be 'CERT-'

- the station_id is assigned by the CIC

- the descriptive name is as defined in the Certification document

Note that the certification tests define the required value for the <descriptive_name>.


7.0 IDENTIFYING MESSAGES RECEIVED FROM MCHS

The following table summarizes the types of messages that MCHS may send to a scanning station and indicates how to identify them. The content of the Subject line should be sufficient for determining whether the email message contains a transaction response to be printed or an administrative message to update administrative files.

The body of each transaction response message further describes the type of response. This information is generally not needed, but could be useful for specialized processing of the responses.

Type of Message Identification in Subject Line Description in Message Body

Transaction Response Messages

MS earch Response Begins with "ARR", "APP", or "DOC" A few lines down from "Mississippi Criminal History Record" contains "Mississippi Rap Sheet".

MS Prosecutor and Court Disposition Forms

Begins with "ARR" Second line of body contains "PROSECUTOR Disposition Form" and "COURT Disposition Form", respectively.

Record Under Review Begins with "ARR" Second line of body has no text.

Third line of body contains "=== RECORD UNDER REVIEW ==="

DNA Database Collection Form

Begins with "ARR" Second line of body contains "DNA Database Collection Form".

MS Reject Notice Begins with "Reject: ARR"

or "Reject: APP"

or "Reject: DOC"

Second line of body contains "TRANSACTION REJECT NOTICE".

MS Warning Notice

(for Type 15 palm print records)

Begins with "Warning: ARR"

or "Warning:: APP"

or "Warning:: DOC"

Second line of body contains "TRANSACTION WARNING NOTICE".

FBI Search Response Begins with "FBI Response" Second line of body contains "FBI Rap Sheet (SRE)".

It also indicates whether it is in response to an "arrest" or an "applicant" transaction.

FBI Error Response Begins with "FBI Response" Second line of body contains "FBI Error Report (ERRT)".

It also indicates whether it is in response to an "arrest" or an "applicant" transaction.

Administrative Messages

Edit Table Download Is "EDT"

ATN Block Is "ATN"

Additional information regarding each type of message is found in Appendices D and E.


8.0 PRINT RESPONSES FROM MCHS ON SCANNING STATION PRINTER REQUIREMENTS

Each scanning station configuration (refer to Section 5.1) must be able to include a printer and must print the responses that MCHS sends to a scanning station.

Responses include those described in Appendix D as well as the first 300 lines of any unidentified responses.

The printed response must begin with the email header lines.

A fixed-width font must be used. (Many of the responses do not format properly unless the scanning station uses a fixed-width font.)

Responses must print on 8 1/2 x 11 paper.

Responses must print automatically, with no human intervention required.


9.0 PRINT TENPRINT AND PALM PRINT CARD AT SCANNING STATION REQUIREMENTS

The following are the requirements to print card images on a livescan:

Printer must be must be able to reproduce FBI-quality fingerprint and palm print images.

Must be able to print on preprinted two-sided card stock and on 8 ½ x 11 paper using an imbedded template such that the image and data formats appear on the paper to look like cards indicated below. Biometric images and text data must be included as indicated below:

Mississippi Criminal Arrest Card: All fingerprint positions, demographic data, and arrest data.

FBI Applicant Card: All fingerprint positions, demographic data, and arrest data.

FBI Palm Print Card FD-884: Palm print images and demographic data. (Fingerprints are not required.) Supplemental card FD-844a is not required.

o For full palms: two cards are required.

o For upper/lower pairs: Four cards are required with one palm pair position on each card. Include the corresponding writer's palm on each card.

o Fill in only the front side of the card but also print the backside of the card.

The operator must be able to enter a new transaction and print it without transmitting it to MCHS.

For APPs, if the transaction was entered only for the purpose of printing the card, the applicant agency ORI may not be known. Therefore, in this situation, the operator must be able to specify whether or not to include the Applicant Agency ORI (in Block 9) on the card.

The operator must be able to retrieve a stored transaction for printing.

Samples of the arrest, applicant, and palm print cards are found in Appendix I.


10.0 STORE, RETRIEVE, RESUBMIT TRANSACTION ON SCANNING STATION REQUIREMENTS

The scanning station must provide a mechanism storing transactions and subsequently for the station operator to retrieve, modify and resubmit transactions.

The scanning station must store all submitted transactions for a minimum of 30 days. Note that some agencies submit a high volume of transactions so 30 days could mean a substantial number of transactions.

An operator must be able to retrieve a stored transaction for printing on the scanning station.

An operator must be able to modify and resubmit a stored transaction to MCHS.

o The station operator must be given the option to send the transaction with either the same TCN or with a new TCN.

o For billable applicants, for a No Charge Applicant Resubmit, the scanning station may automatically populate field 1.10 Transaction Control Reference Number with the TCN of the FBI's ERRT response.

An operator must have the option to save an unsent transaction.

An operator must be able to retrieve an unsent transaction, update it, and send it to MCHS.


11.0 SECURITY REQUIREMENTS

Scanning stations must meet the requirements specified in the version of the MCHS Security Policy that is in effect at the time of certification. The MCHS Security Policy fully incorporates the FBI's CJIS Security Policy that dictates security requirements for systems that access the FBI's NCIC and NGI data.

Security policy includes requirements for transmission of transactions between the station and MCHS, operator authentication and authorization, and requirements if the station hosts other applications in addition to those specified in this document.

Contact the CIC for a copy of the Security Policy.

The vendor will need to contact the agency where the scanning station will be installed to determine their network configuration since it will impact an individual station's security requirements. Then, the vendor must coordinate with the CIC to determine an acceptable implementation of the security requirements.

If scanning station is not directly connected to the State network, vendor must be approved by the CIC to connect to MCHS via VPN-IPSEC services. If vendor is approved to connect via VPN-IPSEC services, split tunneling is not allowed for any purpose, include accessing print services.

Transactions are sent to MCHS using the SMTPS protocol and responses are retrieved from MCHS using the POP3S protocol. The POP3S protocol requires a login as part of the session. The login name and password for a station will be provided prior to installation of each scanning station (refer to Section 5.2).

Additional SMTPS and POP3S requirements are found in Appendices C.1 and D.1.

See Appendix C..2 and D.2 for legacy SMTP and POP3 requirements for some existing livescans and cardscans.


12.0 CIC CERTIFICATION REQUIREMENTS FOR SCANNING STATIONS

For each type of scanning station, each type of submission for each type of agency (as described in Section 4.1), and each make/model of tenprint-only and palm print scanner must be certified by the CIC before they can be installed at a local agency, MDOC, or the CIC.

Refer to the following documents:

Instructions for Sample Transactions to Submit to CIC for Pre-Certification Review

MCHS Tenprint Certification Test Procedures

MCHS Palm Print Submission Test Procedures

o Note that palm prints are allowed to be submitted from each individual site only after completion of Palm Print Certification Phase 4 at each individual site.

Contact the CIC for more information and to schedule certification.

Vendors will be notified, in the future, when they can begin scheduling certification testing for submitting Type 10 records for facial images (aka mugshots).


APPENDIX A CONTENT OF EACH RECORD TYPE IN A TRANSACTION

The ANSI/NIST tenprint transaction includes multiple records. This appendix describes the requirements for each field in each record.

In order to ensure that all of the data in a transaction belongs to the specified individual, it is essential to build completely new records for each new transaction. If data is carried over from a previous transaction, this can cause data to be erroneously associated with a subject or to be incorrectly processed.

The content of many of the fields is determined by valid value lists that must be built using the downloaded edit tables described in Appendix E.1. The agency and vendor may wish to use valid value lists for other fields as well. If so, the content of any valid value lists needs to be coordinated with the CIC.


A.1 Type 1 Transaction Information Record

The Type 1 record is required to be the first record in the tenprint transaction.

The table in this appendix describes the requirements for each of the fields in the Type 1 record.

The following applies to fields 1.07 Print Agency ORI and 1.08 Arrest/Applicant/DOC Agency ORI in the cases where they are user-entered:

o The edit tables must be used to populate valid value lists for use by the operator at the livescan or cardscan and to validate the transaction before it is sent to MCHS.

o For fields that use valid value lists, the operator must not be able to enter any value other than one of the values from the valid value list.

The field type is identified in the "Field" column. Use this to refer to Appendix B.1 for an explanation of how to properly format the field in the NIST record.

The source of the data for each field is also identified in the first column. It is one of the following:

User-entered. Value is entered by the livescan or cardscan operator.

Generated. Value is generated by the scanning station software. It is never entered by the operator.

Hardcoded. Value is specified by the ICD and is hardcoded by the vendor when the scanning station is installed. It is never entered by the operator.

Hardcoded - agency-specific. Value is specified by the CIC in coordination with the agency and is hardcoded by the vendor when the scanning station is installed. It is never entered by the operator.

Pre-set default. The value will be selected by the user from predetermined list of values, but a pre-specified likely value is presented to the operator by the scanning station software. The operator will select a different value if the pre-set default is not the correct value for the transaction. The value must be reset to the pre-set default before the next transaction is entered.

For a couple fields, the source varies depending on the type of scanning station.

Applicability of a field to a type of transaction is indicated in the "ARR", "APP", and "DOC" columns. If there are further conditions with regard to applicability, this is explained in the "Requirements" column. Be sure to refer to Section 4.1 for additional discussion of which fields are applicable to a transaction type depending on the purpose of the submission.

For most fields, the requirements described in the "Requirements" column are the same for each of the three transaction types. If there are differences, the specific requirements are described for each transaction type.

If there are interdependencies between fields, they are included in the Requirements column and identified as cross-field validations.

Note that the field source and value may depend on the type of transaction (ARR, APP, DOC), the type of submission (e.g., Billable Applicants), the type of agency where the scanning station is installed (a local agency, DOC, or the CIC), or the type of scanning station (livescan or cardscan).


Field ARR APP DOC Requirements

1.01

Record Header

Field Type: Simple non-repeating

Source: Generated

ARR APP DOC Required: Yes

Occurrences: 1

Length: Maximum 9

Value and Format:

- The length of this record, including this field.

1.02

Version Number


Source: Hardcoded

This field contains the version number of the Interface Control Document.


Occurrences: 1

Length: Fixed length of 4

Value and Format:

- Must be '0502'.

1.03

Transaction Content

Field Type: Group repeating

Source: Generated

The information in this field identifies the contents of the transaction in terms of record types and the sequence in which they appear.


Occurrences: Determined by actual number of records present in the transaction.

Value and Format:

- Both Type and IDC must be populated in an occurrence.

- The first occurrence pair indicates how many records (other than the Type 1 record are in the transaction.

- The subsequent occurrences are an index to each of the records (other than the type 1 record) that are included in the transaction. They must be recorded in the occurrences in this field in the same sequence as the records actually appear in the transaction.

First Record Category Code

- first occurrence of Transaction Content

ARR APP DOC Length: 1

Value and Format:

- Must be '1' indicating Record Type 1.

Content Record Count

- first occurrence of Transaction Content

ARR APP DOC Length: Maximum 2

Value and Format:

- Total number of Type 2, 4, 10, and 15 records in the transaction. (Do not count the Type 1.)

Record Category Code

– subsequent occurrences


Value and Format:

- Record Type (i.e., '2', '4', '10' or '15') of a record in the transaction.

Information Designation Character

– subsequent occurrences


Value and Format: A unique number assigned to the Type 2, 4, 10, or 15 records.

- See Appendix B.4 for additional requirements.

1.04

Type of Transaction (TOT)


Source: Generated


Occurrences: 1


Value and Format:

- Must be one of the following values:

'APP' Applicant Transaction

'ARR' Arrest Transaction

'DOC' DOC Inmate Receipt Transaction



1.05

Transaction Date


Source: Generated

This field contains the date the transaction is created.


Occurrences: 1


Value and Format:

- Must be in the format CCYYMMDD where CC is 19 or 20 and YY is 00 through 99. CCYYMMDD must be a valid calendar date and value must not be in the future.

1.07

Print Agency ORI


Source:

-- For transactions submitted from a livescan, hardcoded - agency-specific

-- For transactions submitted from a cardscan, user-entered

This field contains the ORI of the agency responsible for capturing the fingerprints from the subject.


Occurrences: 1


Value and Format:

- Must be on the Agency edit table.

- For livescans, this field must be the same agency ORI that is assigned to the livescan by the CIC.

1.08

Arrest/Applicant/DOC Agency ORI


Source:

-- For ARRs, generated

-- For APPs:

--- For transactions submitted from a local agency, either user-entered or pre-set default

--- For Instate Inquiry Only transactions submitted from the CIC, either user-entered or hardcoded - agency-specific

---- For all other transactions submitted from the CIC, user-entered

-- For DOCs, hardcoded - agency-specific or pre-set default


Occurrences: 1

Length: Maximum 9

Value and Format:

- For ARRs, copy value from field 2.702; must be on the Enforce Agency edit table.

- For APPs, value must be on the Agency edit table.

- For DOCs, value must be on the Correct Agency edit table.

Note: On the display, shorten the name to the applicable agency type based on the type of transaction.



1.09

Transaction Control Number (TCN)


Source:

-- For production transactions, generated

-- For test transactions, user-entered


Occurrences: 1

Length: Minimum 1; maximum 40

Value and Format:

- A unique number assigned to the transaction.

- For production transactions, the format is:

< station_id>-<current_date>-<sequence_number>

where:

-- the station_id is assigned by the CIC

-- the current_date is in the format CCYYMMDD

-- the sequence_number is a 4-digit number from 0001 to 9999. When 9999 is used, reset the sequence_number to 0001.

- For test transactions, the format is:

CERT-< station_id>-<descriptive_name>

where:

-- the first 5 characters must be 'CERT-'

-- the station_id is assigned by the CIC

-- the descriptive name is as defined in the Certification document or other names assigned to additional test transactions

1.10

Transaction Control Ref No (TRN)


Source:

-- For No Charge Applicant Resubmits, pre-populated or user-entered

-- For all other types of submission, this field is not applicable

This field contains the FBI-assigned TCN that was in the FBI Error Response message for the rejected Billable Applicant transaction.

APP Required: Yes for No Charge Applicant Resubmits (Must not be present for any other type of submission)

Occurrences: 1


Value and Format:

- May contain alphabetic, numeric, or any printable 7-bit ascii character.

1.11

Native Scanning Resolution


Source: Hardcoded

The size of a pixel in millimeters.


Occurrences: 1


Value and Format:

- Must be '19.69'.

1.12

Nominal Transmitting Resolution


Source: Hardcoded

The size of a pixel in millimeters.


Occurrences: 1


Value and Format:

- Must be '19.69'.


A.2 Type 2 Tenprint Data Record

The Type 2 record contains descriptive information about the individual and, for an ARR, the arrest information.

A scanning station must not allow a transaction to be sent to MCHS unless each field validates against the requirements in this section. The scanning station must perform each of the validations identified in the table in this section.

Scanning station must pre-populate fields that have a category of 'Hardcoded-default' and all other fields must not be prepopulated.

Scanning station software must not allow an operator to override the values in fields that are "Generated", "Hardcoded", or "Hardcoded - agency-specific". Also, these fields do not need to be displayed.

The values in all fields, other than the preset fields described above, must be cleared before an operator can begin entering a new transaction.

The edit tables must be used by the scanning station software to populate valid value lists for use by the operator at the scanning station and to validate the transaction before it is sent to MCHS.

For fields that use valid value lists, the scanning station operator must not be able to enter any value other than one of the values from the valid value list.

For fields that do not use valid value lists, the scanning station must display an error to the operator if the value does not meet the field validation requirements specified in this appendix.

For new certifications, fields with cross-field validations, the scanning station must display an error to the operator if the valued do not meet the cross-field validation requirements specified in this appendix.

For fields that do not use valid value lists or are not all numeric, an operator must be able to enter text in mixed case.

On cardscans, the fields must be presented to the operator in the sequence that they appear on the Mississippi Criminal Arrest Card and the FBI Applicant Card.

On cardscans, creating DOC transactions is not applicable (since MDOC does not use printed cards at this time).


The requirements for field 2.084 and record Type 4 to specify a partial amputation, a full distal amputation, and an otherwise unprintable rolled finger position are in Appendix A.6.

A field type for each field is identified in the "Field" column. Use this to refer to Appendix B.1 for an explanation of how to properly format the field in the NIST record.






Pre-set default. The value will be selected by the user from predetermined list of values, but a pre-specified likely value is presented to the operator by the scanning station software. The operator will select a different value if the pre-set default is not the correct value for the


transaction. The value must be reset to the pre-set default before the next transaction is entered.

In one or two cases, the source varies depending on the type of scanning station.

Applicability of a field to a type of transaction is indicated in the "ARR", "APP", and "DOC" columns. If there are further conditions with regard to applicability, this is explained in the "Requirements" column. Refer to Section 4.1 for additional discussion of which fields are applicable to a transaction type depending on the purpose of the submission.

For most fields, the requirements described in the "Requirements" column are always the same for each of the three transaction types. If there are differences, the different cases are described.

The valid values of many of the Type 2 fields are defined in the Edit Tables that are downloaded to the scanning station (see Appendix E.1). Otherwise, the types of characters allowed in the field are described in the "Requirements" column. The following abbreviations are used:

A = alphabetic, upper or lower case,

N = numeric,

S = special characters; this may be followed by further restrictions that indicates that "only" the specified subset of special characters is allowed.

If there are interdependencies between fields, they are included in the Requirements column and identified as cross-field validations.

Note that the field source, value and other requirements may depend on type of transaction (ARR, APP, DOC), the type of submission (e.g., Billable Applicants), the type of agency where the scanning station is installed (a local agency, DOC, or the CIC), or the type of scanning station (livescan or cardscan).



2.001

Record Header


Source: Generated


Occurrences: 1

Length: Maximum 9

Value and Format:

- Length of this record, including this field.

2.002

Information Designation Character (IDC)


Source: Generated


Occurrences: 1

Length: Maximum 9

Value and Format:

- A unique number assigned to the record.


2.009

Originating Agency Case #


Source: User-entered

ARR APP Required: No

Occurrences: 1


Value and Format:

- Characters: ANS, only spaces and hyphens

2.016

Social Security #

Field Type: Simple repeating


ARR APP DOC Required: No

Occurrences: Maximum 4


Value and Format:

- Characters: N

- The following values are not allowed:

positions 1-3 (area) cannot be 000 or 666 or 900-999

positions 4-5 (group) cannot be 00

positions 6-9 (serial number) cannot be 0000

cannot be 111111111

2.017

Miscellaneous Id #





Value and Format:

- Both Type and Value must be populated in an occurrence.

Misc Id # Type ARR APP DOC Length: Maximum 15

Value and Format:

- Value must be in Misc Number Type edit table.

Misc Id # Value ARR APP DOC Length: Maximum 12

Value and Format:

- Characters: ANS, only hyphens.

2.018

Name



This field contains the subject's name and any aliases.



Value and Format:

- Both Last Name and First Name must be populated in an occurrence.

- To specify a nickname: A single 'X' must be in the First Name field with the nickname in the last name field. Middle name and name suffix fields must be null.



Last Name ARR APP DOC Length: Maximum 35

Value and Format:

- Characters: AS, only hyphens, apostrophes, and spaces

First Name ARR APP DOC Length: Maximum 20

Value and Format:


Middle Name ARR APP DOC Length: Maximum 20

Value and Format:


Name Suffix ARR APP DOC Length: Maximum 4

Value and Format:

- Value must be in Name Suffix edit table.

2.020

Place of Birth




Occurrences: 1


Value and Format:

- Value must be in the Place of Birth edit table.

2.021

Country of Citizenship




Occurrences: 1


Value and Format:

- Value must be in the Country edit table.



2.022

Date of Birth






Value and Format:

- Must be in the format CCYYMMDD where CC is 19 or 20 and YY is 00 through 99. CCYYMMDD must be a valid calendar date.

- Value cannot be more than 99 years before Transaction Date with the exception that 19000101 must be allowed. (Cross-field validation)

- For APPs for SOR and DOCs, value must be 14 or more years less than the Date Printed. (Cross-field validation)

- For ARRs:

-- Value must be 13 or more years less than Date Printed. (Cross-field validation)

-- Value must be 13 or more years less than Date of Offense. However if Date of Offense is not supplied, Date of Birth must be 13 or more years less than Date of Arrest. (Cross-field validation)

-- Value must be consistent with Arrest Type and Date of Offence. Age at Date of Offence must be less than 18 if Arrest Type is 'Juv-As-Adult' -or-greater than or equal to 18 if Arrest Type is 'Adult'. However if Date of Offense is not supplied, age at Date of Arrest must be less than 18 if Arrest Type is 'Juv-As-Adult' -or-greater than or equal to 18 if Arrest Type is 'Adult'. (Cross-field validation)

2.024

Sex/Gender




Occurrences: 1

Length: Maximum 6

Value and Format:

- Characters: Value must be in the Sex edit table.

2.025

Race




Occurrences: 1

Length: Maximum 7

Value and Format:

- Characters: Value must be in the Race edit table.

2.02

Scars, Marks, and Tattoos (SMT)





Value and Format:

- Code must be populated in an occurrence.

SMT Code ARR APP DOC Length: Maximum 20

Value and Format:

- Value must be in Tattoo edit table.

SMT Description ARR APP DOC Length: Maximum 20

Value and Format:

- Characters: ANS



2.027

Height




Occurrences: 1


Value and Format:

- Value must be in feet and inches (fii) format where f must be from 4 to 7 and ii must be from 00 to 11.

2.029

Weight




Occurrences: 1


Value and Format:

- Value must be in the range 070 through 600.

- For values less than 100, a leading zero is required.

2.031

Eye Color




Occurrences: 1

Length: Maximum 10

Value and Format:

- Value must be in the Eye Color edit table.

2.032

Hair Color




Occurrences: 1

Length: Maximum 10

Value and Format:

- Value must be in the Hair Color edit table.

2.035

Palmprints Available



ARR DOC Required: Yes

Occurrences: 1

Length: Maximum 3

Value and Format:

- Value must be in the Yes/No edit table.

2.036

Photo Available



ARR DOC Required: Yes

Occurrences: 1

Length: Maximum 3

Value and Format:

- Value must be in the Yes/No edit table.

2.037

Reason Fingerprinted


Source:

-- For Billable Applicant APPs and No Charge Applicant Resubmit APPs, user-entered

-- For Law Enforcement Applicant, Criminal Inquiry Only, Instate Inquiry APPs, and APP for SORs, hardcoded

APP Required: Yes


Length: Maximum 30

Value and Format:

- For Billable Applicant APPs and No Charge Applicant Resubmit APPs, value must be in the Reason Fingerprinted edit table.

- For Law Enforcement Applicant APPs, value must be 'Law Enforcement'.

- For Criminal Inquiry Only APPs, value must be 'CRIMINAL INQUIRY'.

- For Instate Inquiry APPs, value must be 'Instate Inquiry Only'.

- For APP for SOR, value must be 'Sex Offender Reg'



2.038

Date Printed


Source:

-- For all transactions submitted from a livescan, generated (the current date)

-- For APPs submitted from a cardscan, user-entered

-- For ARRs and DOCs submitted from a cardscan, generated

This field contains the date the subject's fingerprints were captured.


Occurrences: 1


Value and Format:


- Value must be less than or equal to the current date.

- Value must be less than or equal to Transaction Date. (Cross-field validation)

- For ARRs submitted from cardscans, copy the value from field 2.045 Date of Arrest.

(Note: The CIC sets maximums for how old submitted prints can be based on various factors. These may change from time to time and scanning stations do NOT implement these validations.)

2.039

Employment

Field Type: Group non-repeating


ARR APP Required: No

Occurrences: 1

If Employment is present, at least one of Occupation, Employer Name, or Address 1, 2 or 3 must be populated.

Occupation ARR APP Length: Maximum 50

Value and Format:

- Characters: ANS

Employer Name ARR APP Length: Maximum 29

Value and Format:

- Characters: ANS

Employer Address 1 ARR APP Length: Maximum 29

Value and Format:

- Characters: ANS


Value and Format:

- Characters: ANS


Value and Format:

- Characters: ANS

2.041

Residence

Field type: Group non-repeating


ARR APP Required: No with one exception

For APPs for SOR: Field is required

Occurrences: 1

If Residence is present, at least one of Address 1, 2 or 3 must be populated.

Residence Address 1 ARR APP Length: Maximum 35

Value and Format:

- Characters: ANS


Value and Format:

- Characters: ANS




Value and Format:

- Characters: ANS

2.045

Date of Arrest



ARR Required: Yes

Occurrences: 1


Value and Format:



- Value must be less than or equal to Transaction Date and Date Printed. (Cross-field validation)

2.056

Caution Comments



ARR DOC Required: No

Occurrences: 1

Length: Maximum 50

Value and Format:

- Characters: ANS

2.067

Image Capture Equipment

Make, Model, and Serial Number of the device that was used to capture the fingerprints


Source: Hardcoded - agency-specific


Occurrences: 1

Value and Format:

- Make, Model, and Serial Number must all be populated.

Equipment Make ARR APP DOC Length: Maximum 25

Value and Format:

- Coordinate with the CIC to obtain exact text. Must be consistent for all stations from the same vendor.

Equipment Model ARR APP DOC Length: Maximum 25

Value and Format:

- Coordinate with the CIC to obtain exact text. Must be consistent for all stations from the same vendor.

Equipment Serial # ARR APP DOC Length: Maximum 25

Value and Format:

- Unique identification assigned by vendor.



2.084

Amputated or Bandaged



ARR APP DOC Required: In accordance with the following:

All 10 rolled finger positions must be accounted for in the transaction so there must be either a Type-4 record with an image or an indicator in field 2.084, or both, for each of the 10 rolled finger positions.

MCHS follows the FBI EBTS specification for using field 2.084 to specify partial amputation vs full amputation vs unprintable for any reason other than full amputation. Refer to Appendix A.6 for detailed explanation.


Value and Format:

- Both Finger Number and Amputated or Bandaged Code must be populated in an occurrence.

- Must comply with Appendix A.6.

Finger Position ARR APP DOC Length: Maximum 2

Characters: N

Value and Format:

- Must be one of the following values:

1 Right thumb 2 Right index finger 3 Right middle finger 4 Right ring finger 5 Right little finger 6 Left thumb 7 Left index finger 8 Left middle finger 9 Left ring finger 10 Left little finger

Amputated or Bandaged Code ARR APP DOC Length: Maximum 2

Value and Format:

- Characters: Value must be on AMP or BAND Code edit table.

2.701

Arrest Tracking #


Source:

-- For cardscans, user-entered

-- For livescans, generated

ARR Required: Yes

Occurrences: 1


Value and Format:

- Characters: AN

- Field must have correct check digit. See Appendix F.

- For livescans, value must be within a range allocated to the livescan. See Appendix E.2.

2.702

Arrest Agency ORI


Source: Pre-set default (In some cases, this may be hardcoded - agency-specific. In order to use this option, it must first be coordinated with the CIC.)

ARR Required: Yes

Occurrences: 1


Value and Format:

- Value must be in the Enforce Agency edit table.



2.703

Driver's License





Value and Format:

- State and License # must both be present in an occurrence.

Driver's License State ARR APP DOC Length: Fixed length of 2

Value and Format:

- Value must be in the State edit table.

Driver's License # ARR APP DOC Length: Maximum 20

Value and Format:

- Characters: ANS

2.704

Arrest Type



ARR Required: Yes

Occurrences: 1

Length: Maximum 14

Value and Format:

- Value must be in the Arrest Type edit table.

2.705

Arrest Charge Set



ARR Required: Yes


Value and Format:

- The following subfields are required in each occurrence:

Citation # Counts Action

Citation ARR Length: Maximum 21

Value and Format:

- For transactions submitted from a local agency, value must be in the Statute edit table.

- For transactions submitted from the CIC, value must be in the Statute_CIC edit table.

Charge Description ARR Length: Maximum 140

Value and Format:

- Characters: ANS

Supplement

This field contains information that indicates the role of the subject in this crime. For example: 'Conspiracy, Abet'.

ARR Length: Maximum 40

Value and Format:

- Each individual value must be in the Supplement edit table.

- Allow multiple values delimited by a comma if more than one value is entered.

- Each individual value has a maximum length of 15.

Severity ARR Length: Maximum 11

Value and Format:

- Value must be in the Severity edit table.

# Counts ARR Length: Maximum 3

Value and Format:

- Characters: N




Date of Offense ARR Length: Fixed length of 8

Value and Format:



- Value must be less than or equal to Transaction Date, Date Printed, and Date of Arrest. (Cross-field validation)

Action ARR Length: Maximum 25

Value and Format:

- Value must be in the Enforce Event edit table.

Charge Remarks ARR Length: Maximum 50

Value and Format:

- Characters: ANS

2.706

Fee Paid


Source:

-- For Billable Applicant APPs, user-entered

-- For No Charge Resubmits, Law Enforcement Applicant, Criminal Inquiry Only, and Instate Inquiry APPs, this field is not applicable.

This field contains the amount of the fee charged for this applicant background check.

APP Required: No

Occurrences: 1

Length: Maximum 6

Value and Format:

- Characters: NS, only period.

- Must be in whole dollars or dollars and cents.

2.707

Response Address



APP Required: No

Occurrences: 1

Response Addressee APP Length: Maximum 50

Value and Format:

- Characters: ANS

Response Address 1 APP Length: Maximum 35

Value and Format:

- Characters: ANS


Value and Format:

- Characters: ANS


Value and Format:

- Characters: ANS

Response Phone # APP Length: Maximum 20

Value and Format:

- Characters: ANS



2.709

DOC #



DOC Required: Yes

Occurrences: 1

Length: Maximum 10

Value and Format:

- Characters: AN


A.3 Type 4 High-Resolution Grayscale Fingerprint Image Record

The Type 4 record is used for fingerprint images. A set of images is required in ARR, APP, and DOC tenprint transactions.

A scanning station must not allow a transaction to be sent to MCHS unless each field validates against the requirements in this section.

The fingerprint image must

o Be captured using an FBI-approved scanner

o Be compressed using FBI-approved WSQ compression software. Also, any image manipulation (e.g., cropping) must be done before the image is compressed.

Usually there are 14 Type 4 records in a tenprint transaction -- 10 individual rolled finger positions, the left and right four-finger plain positions, and the two plain thumb positions. There may be fewer positions as described in Appendix A.6. All fingers must be accounted for in either Type 4 records or in field 2.084 in the Type 2 record.

At least one Type 4 record is required in a transaction.

Type-4 fingerprint records that are included for a hand must be consistent, e.g., if one or more rolled fingers for a hand are present, then the corresponding plain four-finger image must be present etc.

The table in this Appendix describes the requirements for each of the fields in the Type 4 record.

The content and format of the Type 4 must comply with the specifications in the Data Format for the Interchange of Fingerprint Information, American National Standards Institute (ANSI/NIST ITL 1-2011) (subsequently referred to by 'NIST-2011'.) The CIC may impose additional requirements and, if so, they are identified in Value and Format in the Requirements column. If there are interdependencies between fields, they are included in the Requirements column.









Field

Byte Position

Requirements

Record Header (4.001)

Field Type: Four byte binary number

Source: Generated

1 - 4 Required: Yes

Value and Format: The length of this record, including this field. Must comply with specifications in NIST-2011.

- For livescans, the minimum size is 5,000 bytes.

Information Designation Character (4.002)

Field Type: One byte binary number

Source: Generated

5 Required: Yes

Value and Format: A unique number assigned to the record. See Appendix B.4 for additional requirements. Must comply with specifications in NIST-2011.

Impression Type (4.003)

Field Type: One byte binary code

Source: Generated

6 Required: Yes

Value and Format: A code describing the manner in which the fingerprint image was obtained. Must comply with specifications in NIST-2011.

- The field value must be one of the following:

0 Livescan plain impression 1 Livescan rolled impression 2 Cardscan plain impression 3 Cardscan rolled impression

- The value must be '0' or '1' for a livescan.

- The value must be '2' or '3' for a cardscan.

- If a concentrator supports both livescans and cardscans, the value must be consistent with the type of scanning station that sent the transaction to the concentrator.

- The value must coincide with the value of Finger Position, e.g., if the Finger Position is '2', then the Impression Type must be either '1' or '3'.

Friction Ridge Generalized Position (4.004)

Field Type: Six binary byte codes

Source: Generated

7 - 12 Required: Yes

Value and Format: This array of bytes lists the finger positions that correspond to the fingerprint image. Must comply with specifications in NIST-2011.

- Value of byte position 7 of this field must be one of the following finger positions:

1 Right thumb 2 Right index finger 3 Right middle finger 4 Right ring finger 5 Right little finger 6 Left thumb 7 Left index finger 8 Left middle finger 9 Left ring finger 10 Left little finger 11 Plain right thumb 12 Plain left thumb 13 Plain right four fingers 14 Plain left four fingers

- Fill all other byte positions with 255 to indicate unused.


Field

Byte Position

Requirements

Image Scanning Resolution (4.005)


Source: Generated

13 Required: Yes

Value and Format: A code indicating which image scanning resolution was used. Must comply with specifications in NIST-2011.


0 if half of the minimum scanning resolution is used 1 if half of the native scanning resolution is used

Horizontal Line Length (4.006)

Field Type: Two byte binary number

Source: Generated


Value and Format: The number of pixels in a horizontal line of pixels in the image. Must comply with specifications in NIST-2011.

-The maximum number depends on the type of fingerprint image as follows:

Finger Position Maximum Value

1 - 10 Rolled Impressions Fingers 800 11 - 12 Plain Thumb Impressions 500 13 - 14 Four Finger Plain Impressions 1600 - The value of this field must match the corresponding value in the image data.

Vertical Line Length (4.007)

Field Type: Two byte binary number

Source: Generated


Value and Format: The number of horizontal lines in the image. Must comply with specifications in NIST-2011.

- The maximum number depends on the type of fingerprint image as follows:

Finger Position Maximum Value

1 - 10 Rolled Impressions Fingers 750 11 - 12 Plain Thumb Impressions 1500 13 - 14 4 Finger Plain Impressions 1500 - The value of this field must match the corresponding value in the image data.

Compression Algorithm (4.008)


Source: Hardcoded

18 Required: Yes

Value and Format: Specifies the algorithm used to compress the binary data. Only one algorithm, Wavelet Scalar Quantization is allowed by MCHS and the FBI/NGI system. Must comply with specifications in NIST-2011.

- The field value must be '1'.


Field

Byte Position

Requirements

Image Data (4.009)

Field Type: Variable length binary image


19 - end of record

Required: Yes if the record is present. In accordance with the following:

All 10 rolled finger positions must be accounted for in the transaction so there must be either a Type-4 record with an image or an indicator in field 2.084, or both, for each of the 10 rolled finger positions.


Value and Format: The fingerprint image that has been compressed by the WSQ compression algorithm. Must comply with specifications in NIST-2011.

- A nominal compression ratio of 15:1 is required by the FBI. Therefore, the following computation should result in a value of approximately 15:

Horizontal Line Length x Vertical Line Length -------------------------------------------------------------- length of this Image field

- The FBI's guideline for this field is as follows:

1. On average, an image should have a compression ratio of 15:1.

2. On average, if the total size of a transaction with a full set of fingerprints (no amputations) is less than 650 KB, then the images are probably compressed too much.


A.4 Type 10 Facial and SMT Image Record (future)

TYPE 10 RECORDS ARE NOT CURRENTLY ALLOWED

The Type 10 record is used for facial images and images of scars, marks, and tattoos.

Type 10 records are optional in ARR and DOC transactions.

Type 10 records are currently not allowed in APP transactions.

The facial photo or SMP photo image must be compressed using FBI-approved WSQ compression software. Also, any image manipulation (e.g., cropping) must be done before the image is compressed.

In a transaction, there may be up to four Type 10 records with facial images (typically frontal without glasses, frontal with glasses, left profile and right profile) and up to three Type 10 records with SMT images.

The facial images must follow Subject Acquisition Profile (SAP) Level 20 (Legacy Mugshot), Level 30 (Basic Mugshot), or Level 40 (Higher Resolution Mugshot) requirements and guidelines. Within a transaction, all facial image records must be the same SAP level. SAP Level 40 is preferred since it is useful for facial recognition. Only facial images of SAP Level 40 will be accepted by the FBI.

The table in this Appendix describes the requirements for each of the fields in the Type 10 record.


The second and third columns indicate which fields are applicable to facial images and which are applicable to scars, marks and tattoos.









Field Facial SMT Requirements

10.001

Record Header


Source: Generated

Face SMT Required: Yes

Occurrences: 1

Value and Format: The length specified in this field includes this field. Must comply with specifications in NIST-2011.

10.002



Source: Generated


Occurrences: 1

Value and Format: A unique number assigned to the record. Must comply with specifications in NIST-2011.


10.003

Image Type




Occurrences: 1

Value and Format: Must comply with specifications in NIST-2011.

- Value must be one of the following: 'FACE', 'SCAR', 'MARK', 'TATTOO'.

10.004

Source Agency ORI


Source:

Generated - populate with same value as 1.07 Print Agency ORI


Occurrences: 1


- Value must be same as value in field 1.07 Print Agency.

10.005

Photo Capture Date


Source:

For livescans: Generated

For cardscans: User-entered


Occurrences: 1



10.006

Horizontal Line Length


Source: Generated


Occurrences: 1


- For facial images, the minimum value depends on the 10.013 Subject Acquisition Level SAP Level as follows:

SAP Level Minimum Value

20 384 30 480 40 768 - For SMT images, the minimum value is 100.



10.007

Vertical Line Length


Source: Generated


Occurrences: 1


- For facial images, the minimum value depends on the 10.013 Subject Acquisition Profile SAP Level as follows:

SAP Level Minimum Value

20 384 30 600 40 1024

- For SMT images, the minimum value is 100.

- For facial images, the aspect ratio (HLL/VLL) depends on the 10.013 Subject Acquisition Profile SAP Level as follows:

SAP Level Aspect Ratio

20 range from 3:4 to 1:1 30 4:5 40 3:4

10.008

Scale Units


Source: Generated


Occurrences: 1


- Value must be '1' or '2'.

10.009

Transmitted Horizontal Pixel Scale


Source: Generated


Occurrences: 1



10.010

Transmitted Vertical Pixel Scale


Source: Generated


Occurrences: 1



- For facial images, the pixel aspect ratio (thps/tvps) must be 1:1.



10.011

Compression Algorithm


Source: Generated


Occurrences: 1


- For facial images, the allowable compression algorithms depend on the 10.013 Subject Acquisition Profile SAP Level as follows:

SAP Level Valid Values

20 JPEGB, JPEGL, JP2, JP2L, PNG 30 JPEGB 40 JP2, JP2L

- For SMT images, valid values are: JPEGB, JPEGL, JP2, JP2L, PNG.

(Ref.NIST-2011 Table 15.)

- For SAP Level 40, at least one frontal facial image must be compressed using JP2L.

10.012

Color Space


Source: Generated


Occurrences: 1


- For facial images, the allowable color spaces depend on the 10.013 Subject Acquisition Profile SAP Level as follows:

SAP Level Valid Values

20 RGB, SRGB, YCC, SYCC, GRAY 30 RGB, SRGB 40 SRGB

- For SMT images, valid values are: RGB, SRGB, YCC, SYCC, GRAY.

(Ref. NIST-2011 Table 16.)

10.013

Subject Acquisition Profile


Source: User-entered or Generated

Face Required: Yes

Occurrences: 1


- Must be one of the following SAP Levels:

20 Legacy Mugshot 30 Basic Mugshot 40 Higher Resolution Mugshot

(Ref. NIST-2011, Table 10.)

- A value of '40' requires that field 10.023 be present and populated. (Cross-field validation)






10.016

Scanned Horizontal Pixel Scale


Source: Generated

Face SMT Required: No

Occurrences: 1



10.017

Scanned Vertical Picture Scale


Source: Generated


Occurrences: 1



10.018

Distortion


Source: Generated

Face Required: No

Occurrences: 1


- Distortion Code, Distortion Measurement Code, and Distortion Severity Code must be populated.

Distortion Code Value and Format: Must comply with specifications in NIST-2011.

- Value must be 'Barrel, 'Inflated', or 'Pincushion'.

Distortion Measurement Code Value and Format: Must comply with specifications in NIST-2011.

- Value must be ''E' or 'C'.

Distortion Severity Code Value and Format: Must comply with specifications in NIST-2011.

- Value must be 'Mild', 'Moderate', or 'Severe'.

10.019

Lighting Artifacts



Face Required: No



- Value must be 'F', 'H', or 'R'.

10.020

Subject Pose



Face Required: No

Occurrences: 1

Value and Format: Must comply with specifications in NIST-2011, including the valid subject pose code values in Table 60.

- A value of 'A' requires that field 10.021 be present and populated. (Cross-field validation)

- A value of 'D' requires that field 10.025 be present and populated. (Cross-field validation)

- There must be at least one record with a frontal pose in the transaction. That record must be either: - Subject Pose of 'F', or - Subject Pose of 'D' with Subject Pose Angles (10.025) Yaw, Pitch, and Roll of 0, 0, and 0.

- Subject Pose of 'A' with Pose Offset Angle 0.



10.021

Pose Offset Angle



Face Required: Must be present if field 10.020 Subject Pose has the value 'A'.

The field should not be present if field 10.020 has a value other than 'A'.

Occurrences: 1


- Value must be in the range -180 through +180.

10.023

Photo Acquisition Source


Source: Hardcoded

Face Required: Must be present if field 10.013 Subject Acquisition Profile has the value '40' or greater.

Occurrences: 1


- Photo Attribute Code must be present and populated.

- If Photo Attribute Code is 'VENDOR', Description must be populated in each occurrence.

- If Photo Attribute Code is any other value, Vendor-specific Description must be null.

Photo Attribute Code Value and Format: Must comply with specifications in NIST-2011 including the valid subject acquisition source type attribute code values in Table 61.

Vendor-Specific Description Required: Must be present if Photo Attribute Code is 'VENDOR'.


- Length: Maximum 7

10.024

Subject Quality Scores


Source: Generated

Face Required: No



- Quality Value, Algorithm Vendor Identification, and Algorithm Product Identification must be populated in each occurrence.

Quality Value Value and Format: Must comply with specifications in NIST-2011.


Algorithm Vendor Identification Value and Format: Must comply with specifications in NIST-2011.

- Value must be 4-character hexadecimal.

Algorithm Product Identification Value and Format: Must comply with specifications in NIST-2011.




10.025

Subject Pose Angles



Face Required: Must be present if field 10.020 Subject Pose has the value 'D'.

The field should not be present if field 10.020 has a value other than 'D'.

Occurrences: 1


- Yaw Angle, Pitch Angle, and Roll Angle must be present and populated.

- If any of Yaw Uncertainty, Pitch Uncertainty, and Roll Uncertainty is present, then all three fields must be present and populated.

Yaw Angle Value and Format: Must comply with specifications in NIST-2011.


Pitch Angle Value and Format: Must comply with specifications in NIST-2011.


Roll Angle Value and Format: Must comply with specifications in NIST-2011.


Uncertainty in Degrees for Ya Value and Format: Must comply with specifications in NIST-2011.


Uncertainty in Degrees for Pitch Value and Format: Must comply with specifications in NIST-2011.


Uncertainty in Degrees for Roll Value and Format: Must comply with specifications in NIST-2011.


10.026

Subject Facial Description





Value and Format: Must comply with specifications in NIST-2011, including the valid subject facial description attribute code values in Table 62.

- Length: Maximum 20

10.027

Subject Eye Color




Occurrences: 1

Value and Format: Must comply with specifications in NIST-2011, including the valid eye color attribute code values in Table 17.

- The value in this field must correspond to the value in the Type 2 record field 2.031.



10.028

Subject Hair Color




Occurrences: 1, except for one case - see below

Value and Format: Must comply with specifications in NIST-2011, including the valid hair color attribute code values in Table 63.

- If the value of the first occurrence is 'BAL' or 'STR', a second occurrence may be included. The value of the second occurrence must be any valid attribute code except the value in the first occurrence.

- The value in this field must correspond to the value in the Type 2 record field 2.032. If field 10.028 has two occurrences, then one of the two occurrences must correspond to the value in field 2.032.

10.029

2D Facial Feature Points


Source: User entered or Generated

Face Required: No



- Feature Point Type, Feature Point Code, X Coordinate, and Y Coordinate must be populated in each occurrence.

Feature Point Type Value and Format: Must comply with specifications in NIST-2011.


Feature Point Code Value and Format: Must comply with specifications in NIST-2011.

- If Feature Point Type is '1', value must be in the format A.B where the value of A is in the range 1 through 15 and the value of B is in the range 1 through 15.

- If Feature Point Type is '2', value must be a valid anthropometric landmark feature point id in NIST-2011 Table 65.

X Coordinate Value and Format: Must comply with specifications in NIST-2011.


- Value must be less than or equal to value of hll.

Y Coordinate Value and Format: Must comply with specifications in NIST-2011.


- Value must be less than or equal to value of vll.

10.030

Device Monitoring Mode


Source: User entered or Hardcoded


Occurrences: 1

Value and Format: Must comply with specifications in NIST-2011, including the valid device monitoring mode condition values in Table 5.



10.031

Tiered Markup Collection


Source: Generated

Face Required: No

Occurrences: 1

Value and Format: Must comply with specifications in NIST-2011, including the valid tiered markup collection values in Table 66.


10.033

Feature Contours


Source: Generated

Face Required: Must be present if field 10.031 Tiered Markup Collection has the value '5'.

Occurrences: 12


- Feature Contour Code, Number of Points, Horizontal Point Offset, and Vertical Point Offset must be populated in each occurrence.

- Horizontal Point Offset and Vertical Point Offset must occur a minimum of three times, in pairs, up to a maximum that is the value indicated in Number of Points.

Feature Contour Code Value and Format: Must comply with specifications in NIST-2011, including the valid feature contour code values in Table 18.

Number of Points Value and Format: Must comply with specifications in NIST-2011.

- Value must be the number of occurrences of hpo-vpo pairs. Must be a minimum of three points.

Horizontal Point Offset Occurrences: Number of hpo-vpo pairs must be the number specified in nop. See Requirements for Feature Contours.


- Horizontal and Vertical Point Offset are provided in pairs.

- Value must be in the range 0 through 10.006 Horizontal Line Length (hll) value.

Vertical Point Offset Occurrences: Number of hpo-vpo pairs must be the number specified in nop. See Requirements for Feature Contours.


- Value must be in the range 0 through 10.007 Vertical Line Length (vll) value.

10.038

Comment



Face Required: No

Occurrences: 1


- Length: Maximum 126.



10.039

Type-10 Reference Number




Occurrences: 1



10.040

NCIC SMT Code



SMT Required: Yes



- Value must be on the Edit Table SMT. (The MCHS Edit Table is consistent with the NCIC 2000 tables but does not include conditions that are temporary (e.g., a broken bone) or cannot be seen (e.g., a healed bone)).

10.041

SMT Size


Source: Generated

SMT Required: No

Occurrences: 1


- Height and Width must be present and populated.

Height Value and Format: Must comply with specifications in NIST-2011.

- Value must be in the range 1 through 999 centimeters.

Width Value and Format: Must comply with specifications in NIST-2011.

- Value must be in the range 1 through 999 centimeters.

10.042

SMT Descriptors


Source: User entered

SMT Required: No


Value and Format: Must comply with specifications in NIST-2011, including the tables of valid class code and subclass code values indicated below.

– If SMT Code Indicator is 'TATTOO', 'CHEMICAL', 'BRANDED', or 'CUT', then Tattoo Class and Tattoo Subclass must be populated in each occurrence.

- A value in this field requires that field 10.043 be present and populated. (Cross-field validation)

SMT Code Indicator Value and Format: Must comply with specifications in NIST-2011.

- Value must be one of the following:

If 10.003 Image Type = 'SCAR', value must be 'SCAR' or 'PIERCING'.

If 10.003 Image Type = 'MARK', value must be 'MARK'.

If 10.003 Image Type = 'TATTOO', value must be 'TATTOO', 'CHEMICAL', 'BRANDED', or 'CUT.



Tattoo Class Required: Required if SMT Code Indicator is ' 'TATTOO', 'CHEMICAL', 'BRANDED', or 'CUT'.


- If SMT Code Indicator is 'TATTOO', 'CHEMICAL', 'BRANDED', or 'CUT', then the value must be a class code on Table 67 in NIST-2011.

- If SMT Code Indicator is 'SCAR' or 'MARK', then the value must not be present; or must be 'OTHER (for compliance with NIST-2007)'.

- If SMT Code Indicator is 'PIERCING', then the value must be null.

Tattoo Subclass Required: Required if SMT Code Indicator is 'TATTOO', 'CHEMICAL', 'BRANDED', or 'CUT'.


- If SMT Code Indicator is 'TATTOO', 'CHEMICAL', 'BRANDED', or 'CUT', then the value must be a subclass code on Table 67 in NIST-2011 and must correspond to the value Tattoo Class.

- If SMT Code Indicator is 'SCAR' or 'MARK', then the value must not be present; or must be 'MISC' (for compliance with NIST-2007)'.

- If SMT Code Indicator is 'PIERCING', then the value must be null.

Tattoo Description Required: No


- If SMT Code Indicator is 'SCAR' or 'MARK', then this field should be null but may be present (for compliance with NIST-2007).

Length: Maximum 256

10.043

Tattoo Color



SMT Required: Must be present and populated if field 10.003 Image Type is 'TATTOO' and field 10.042 SMT Description is present.

Occurrences: Must have the same number of occurrences as Field 10.042.


- Predominant Color must be populated in each occurrence.

- Additional Color is optional.

Predominant Color SMT Value and Format: Must comply with specifications in NIST-2011, including the valid color code values in Table 68.

Additional Color SMT Occurrences: Maximum 5

Value and Format: Must comply with specifications in NIST-2011, including the valid color code values in Table 68.



10.044

Image Transform





Value and Format: Must comply with specifications in NIST-2011, including the valid image transform values in Table 69.

10.045

Occlusions



Face Required: No



- Occlusion Opacity, Type, Number of Points, Horizontal Point Offset, and Vertical Point Offset must be present and populated.

- Horizontal Point Offset and Vertical Point Offset must occur a minimum of three times, in pairs, up to a maximum that is the value indicated in Number of Points.

Occlusion Opacity Value and Format: Must comply with specifications in NIST-2011, including the valid occlusion opacity code values in Table 20.

Occlusion Type Value and Format: Must comply with specifications in NIST-2011, including the valid occlusion type code values in Table 21.

Number of Points Value and Format: Must comply with specifications in NIST-2011.

- Value must be the number of occurrences of hpo-vpo pairs. Must be a minimum of three points.

Horizontal Point Offset Occurrences: Number of hpo-vpo pairs must be the number specified in nop. See Requirements for Occlusions.


- Horizontal and Vertical Point Offset are provided in pairs.

- Value must be in the range 0 through the 10.006 Horizontal Line Length (hll) value.

Vertical Point Offset Occurrences: Number of hpo-vpo pairs must be the number specified in nop. See Requirements for Occlusions.


- Value must be in the range 0 through the 10.007 Vertical Line Length (vll) value.

10.902

Annotation Information


Source: Generated/Hardcoded/User entered




- Annotation GMT, Processing Algorithm Name Version, Algorithm Owner, and Process Description must be populated in each occurrence.



Greenwich Mean Time Value and Format: Must comply with specifications in NIST-2011.

- Must be in the format YYYYMMDDhhmmssZ.

Processing Algorithm Name Version Value and Format: Must comply with specifications in NIST-2011.


Algorithm Owner Value and Format: Must comply with specifications in NIST-2011.


Process Description Value and Format: Must comply with specifications in NIST-2011.


10.903

Device Unique Identifier


Source: Hardcoded


Occurrences: 1

Value and Format: Must comply with specifications in NIST-2011, including the valid tiered markup collections hexadecimal values in Table 93.

- The first character must be 'M' or 'P'.

10.904

Make Model Serial Number

Make, Model, and Serial Number of device that was used to capture the facial or SMT image


Source: Hardcoded


Occurrences: 1


- Make, Model, and Serial Number must be present and populated.

Make Value and Format: Must comply with specifications in NIST-2011.


Model Value and Format: Must comply with specifications in NIST-2011.


Serial Number Value and Format: Must comply with specifications in NIST-2011.


10.993

Source Agency Name


Source: User entered or Generated


Occurrences: 1

Value and Format:

- Could be obtained from description in Agency edit table using Source Agency ORI.

- Must comply with specifications in NIST-2011.


10.996

Hash


Source: Generated


Occurrences: 1


-Must be 64-character hexadecimal.



10.998

Geographic Sample Acquisition Location




Occurrences: 1


- If either of Latitude Degree Value and Longitude Degree value is present, then both fields must be present and populated.

- If any of Geographic Coordinate Universal Traverse Mercator Zone, Easting, and Northing is present, then all fields must be present and populated.

Universal Time Entry Value and Format: Must comply with specifications in NIST-2011.


Latitude Degree Value Value and Format: Must comply with specifications in NIST-2011.

- Value must be in the range -90 through 90.

- May be integer or decimal.

- If this field contains a decimal value, then Latitude Minute Value and Latitude Second Value must not be populated.

Latitude Minute Value Value and Format: Must comply with specifications in NIST-2011.

- Can only be present if Latitude Degree Value is present.

- Value must be in the range 0 through < 60.


- If this field contains a decimal value, then Latitude Second Value must not be populated.

Latitude Second Value Value and Format: Must comply with specifications in NIST-2011.

- Can only be present if Latitude Minute Value is present.



Longitude Degree Value Value and Format: Must comply with specifications in NIST-2011.



- If this field contains a decimal value, then Longitude Minute Value and Longitude Second Value must not be populated.

Longitude Minute Value Value and Format: Must comply with specifications in NIST-2011.

- Can only be present if Longitude Degree Value is present.



- If this field contains a decimal value, then Longitude Second Value must not be populated.



Longitude Second Value Value and Format: Must comply with specifications in NIST-2011.

- Can only be present if Longitude Minute Value is present.



Elevation Value and Format: Must comply with specifications in NIST-2011.

- Value must be in the range -422.000 through 8848.000.


Geodetic Datum Code Value and Format: Must comply with specifications in NIST-2011, including the valid datum code values in Table 6.

-Value must be 3- to 6-character hexadecimal.

Geographic Coordinate Universal Traverse Mercator Zone


- Must be a valid UTM Zone with one or two digits followed by a single letter.

Geographic Coordinate Universal Traverse Mercator Easting


- Value must be one to six digits.

Geographic Coordinate Universal Traverse Mercator Northing


- Value must be one to eight digits.

Geographic Reference Text Value and Format: Must comply with specifications in NIST-2011.


Geographic Coordinate Other System Identifier Value and Format: Must comply with specifications in NIST-2011.

- If this field is present, Geographic Coordinate Other System Value must be present and populated.


Geographic Coordinate Other System Value Value and Format: Must comply with specifications in NIST-2011.

- If this field is present, Geographic Coordinate Other System Identifier must be present and populated.




10.999

Body Part Image


Source: Generated


Occurrences: 1


- The CIC specifies a nominal compression ratio of 15:1. Therefore, the following computation should result in a value of approximately 15:

Horizontal Line Length x Vertical Line Length --------------------------------------------------------------

length of this image data field

- For facial images, the minimum and maximum size depends on the 10.013 Subject Acquisition Profile SAP Level as follows:

SAP Level Minimum Maximum

20 20,000 120,000 30 20,000 120,000 40 56,000 384,000

- For SMT images, the minimum size is 2,000 bytes and the maximum size is 120,000 bytes.


A.5 Type 15 Variable-resolution Palm Print Image Record

The Type 15 record is used for palm print images.

Type 15 records are allowed and optional in ARR transactions.

Type 15 records are allowed and optional in DOC transactions.

Type 15 records are allowed and optional in APP for SOR transactions.

Palm print images must be 500 ppi.

The palm print image must be compressed using FBI-approved WSQ compression software. Also, any image manipulation (e.g., cropping) must be done before the image is compressed.

Either full palms or upper/lower pairs are accepted from livescans. Full palms are preferred.

Either full palms or upper/lower pairs are accepted from livescans. Support for BOTH full palms and upper/lower pairs are preferred.

For each hand, either the full palm and writer's palm or an upper/lower palm pair and the writer's palm are required.

In accordance with the FBI's "A Practical Guide for Palm Print Capture", the palm impressions must be stored in a Type 15 record in a North/South position. Therefore, if a palm position is collected sideways, the scanning station must rotate the image before including it in a Type 15 record.

The palm prints must be captured in accordance with the FBI's "A Practical Guide for Palm Print Capture", available on fbibiospecs.org website. Note than a full palm and an upper palm must include all fingers, including the distal of each finger.

For cardscans, only the palm impressions are used. Therefore, only the images on the front of the FBI Standard Palm Print Card FD-884 are to be scanned and included in the tenprint transaction.

If any Type 15 records are included in the transaction, there must be a Type 15 record for each palm position. The requirements for fields 15.018 and 15.999 to specify a partial amputation, a full amputation, and an otherwise unprintable palm position are in Appendix A.6.









Pre-set default. The value will be selected by the user from predetermined list of values, but a pre-specified likely value is presented to the operator by the scanning station software. The


operator will select a different value if the pre-set default is not the correct value for the transaction. The value must be reset to the pre-set default before the next transaction is entered.

Also see Section 9 for the requirements to print palm prints on the livescan printer in an FBI Palm Print Card FD-884 card format.


Field Requirements

15.001

Record Header


Source: Generated

Required: Yes

Occurrences: 1

Value and Format: The length specified in this field includes this field. Must comply with specifications in NIST-2011.

15.002



Source: Generated

Required: Yes

Occurrences: 1

Value and Format: A unique number assigned to the record. Must comply with specifications in NIST-2011.


15.003

Impression Type


Source: Generated

Required: Yes

Occurrences: 1

Value and Format: Must comply with specifications in NIST-2011, including valid palm impression type codes on Table 11.


10 Livescan palm 11 Non-livescan palm

- The value must be '10' for a livescan.

- The value must be '11' for a cardscan.

- If a concentrator supports both livescans and cardscans, the value must be consistent with the type of scanning station that sent the transaction to the concentrator.

15.004

Source Agency ORI


Source:

Generated - populate with same value as 1.07 Print Agency ORI

Required: Yes

Occurrences: 1


- Value must be same as value in field 1.07 Print Agency.

15.005

Palmprint Capture Date


Source:

For livescans: Generated

For cardscans: User-entered

Required: Yes

Occurrences: 1




Field Requirements

15.006



Source: Generated

Required: Required if an image (field 15.999) is included in the record. Must not be present if there is no image.

Occurrences: 1


- The maximum value depends on the palm position and is determined based on the Friction Ridge Generalized Position (palm positions) in field 15.013 and dimensions in Table 8 in NIST-2011 as follows:

Palm Position Maximum Value

21 2750 22 900 23 2750 24 900 25 2750 26 2750 27 2750 28 2750 - The value of this field must match the corresponding value in the image data.

15.007



Source: Generated


Occurrences: 1


- The maximum value depends on the palm position and is determined based on the Friction Ridge Generalized Position (palm positions) in field 15.013 and dimensions in Table 8 in NIST-2011 as follows:

Palm Position Maximum Value

21 4250 22 2500 23 4250 24 2500 25 2750 26 2750 27 2750 28 2750 - The value of this field must match the corresponding value in the image data.

15.008

Scale Units


Source: Generated


Occurrences: 1




Field Requirements

15.009



Source: Generated


Occurrences: 1



15.010



Source: Generated


Occurrences: 1



15.011



Source: Generated


Occurrences: 1

Value and Format: Must be 'WSQ20'. (Ref.NIST-2011, Table 15.)

15.012

Bits per Pixel


Source: Generated


Occurrences: 1



15.013

Friction Ridge Generalized Position



Required: Yes

Occurrences: 1

Value and Format: Must comply with specifications in NIST-2011, including the valid palm code values in Table 8.

- Value must be one of the following palm positions:

21 Right Full Palm 22 Right Writer's Palm 23 Left Full Palm 24 Left Writer's Palm 25 Right Lower Palm 26 Right Upper Palm 27 Left Lower Palm 28 Left Upper Palm

- See first page of this appendix for requirements with regard to required palm image sets.

- Can include either a full palm or an upper/lower pair but not both.

- If one of a pair is included, then both upper and lower palm prints must be included in the transaction.

- Cannot have more than one record for the same palm code.


Field Requirements

15.016



Source: Generated

Required: No

Occurrences: 1



15.017

Scanned Vertical Pixel Scale


Source: Generated

Required: No

Occurrences: 1



15.018




Required: In accordance with the following:


Occurrences: 1

Value and Format:

- Both Palm Position Number and Amputated or Bandaged Code must be populated in an occurrence.

- Must comply with Appendix A.6.

Friction Ridge Amputated or Bandaged Position Value and Format: Must comply with specifications in NIST-2011.

- Value must be the same as the value specified in 15.013 Friction Ridge Generalized Position.

Amputated or Bandaged Code Value and Format: Must comply with specifications in NIST-2011.

- Value must be one of the following

UP Fully amputated or otherwise unprintable XX Partially amputated

15.020

Comment



Required: No

Occurrences: 1



15.024

Palmprint Quality Metric


Source: Generated

Required: No



- Friction Ridge Metric Position, Quality Value, Algorithm Vendor Identification and Algorithm Product Identification must be populated in each occurrence.

Friction Ridge Metric Position Value and Format: Must comply with specifications in NIST-2011, including the valid palm code values in Table 8.

- Value must be the same as the value specified in 15.013 Friction Ridge Generalized Position.


Field Requirements

Quality Value Value and Format: Must comply with specifications in NIST-2011.


Algorithm Vendor Identification Value and Format: Must comply with specifications in NIST-2011.

- Value must be 4-character hexadecimal.

Algorithm Product Identification Value and Format: Must comply with specifications in NIST-2011.


15.030



Source: User-entered or Hardcoded

Required: No

Occurrences: 1

Value and Format: Must comply with specifications in NIST-2011, including the valid device monitoring mode condition values in Table 5.

15.902



Source: Generated/Hardcoded/User-entered

Required: No



- Annotation GMT, Processing Algorithm Name Version, Algorithm Owner, and Process Description must be populated in each occurrence.

Greenwich Mean Time Value and Format: Must comply with specifications in NIST-2011.


Processing Algorithm Name Version Value and Format: Must comply with specifications in NIST-2011.


Algorithm Owner Value and Format: Must comply with specifications in NIST-2011.


Process Description Value and Format: Must comply with specifications in NIST-2011.


15.903



Source: Hardcoded

Required: No

Occurrences: 1


- The first character must be 'M' or 'P'.

15.904


Make, Model, and Serial Number of device that was used to capture the palm print image


Source: Hardcoded

Required: No

Occurrences: 1


- Make, Model, and Serial Number must be present and populated.

Make Value and Format: Must comply with specifications in NIST-2011.



Field Requirements

Model Value and Format: Must comply with specifications in NIST-2011.


Serial Number Value and Format: Must comply with specifications in NIST-2011.


15.993

Source Agency Name



Required: No

Occurrences: 1

Value and Format:

- Could be obtained from description in Agency edit table using Source Agency ORI.

- Must comply with specifications in NIST-2011.


15.996

Hash


Source: Generated

Required: No

Occurrences: 1


- Must be 64-character hexadecimal.

15.998




Required: No

Occurrences: 1


- If either of Latitude Degree Value and Longitude Degree value is present, then both fields must be present and populated.

- If any of Geographic Coordinate Universal Traverse Mercator Zone, Easting, and Northing is present, then all fields must be present and populated.

Universal Time Entry Value and Format: Must comply with specifications in NIST-2011.


Latitude Degree Value Value and Format: Must comply with specifications in NIST-2011.



- If this field contains a decimal value, then Latitude Minute Value and Latitude Second Value must not be populated.

Latitude Minute Value Value and Format: Must comply with specifications in NIST-2011.

- Can only be present if Latitude Degree Value is present.



- If this field contains a decimal value, then Latitude Second Value must not be populated.


Field Requirements

Latitude Second Value Value and Format: Must comply with specifications in NIST-2011.

- Can only be present if Latitude Minute Value is present.



Longitude Degree Value Value and Format: Must comply with specifications in NIST-2011.



- If this field contains a decimal value, then Longitude Minute Value and Longitude Second Value must not be populated.

Longitude Minute Value Value and Format: Must comply with specifications in NIST-2011.

- Can only be present if Longitude Degree Value is present.



- If this field contains a decimal value, then Longitude Second Value must not be populated.

Longitude Second Value Value and Format: Must comply with specifications in NIST-2011.

- Can only be present if Longitude Minute Value is present.



Elevation Value and Format: Must comply with specifications in NIST-2011.

- Value must be in the range -422.000 through 8848.000.


Geodetic Datum Code Value and Format: Must comply with specifications in NIST-2011, including the valid datum code values in Table 6.

- Value must be 3- to 6-character hexadecimal.

Geographic Coordinate Universal Traverse Mercator Zone


- Must be a valid UTM Zone with one or two digits followed by a single letter.

Geographic Coordinate Universal Traverse Mercator Easting


- Value must be one to six digits.

Geographic Coordinate Universal Traverse Mercator Northing


- Value must be one to eight digits.

Geographic Reference Text Value and Format: Must comply with specifications in NIST-2011.



Field Requirements

Geographic Coordinate Other System Identifier Value and Format: Must comply with specifications in NIST-2011.

- If this field is present, Geographic Coordinate Other System Value must be present and populated.


Geographic Coordinate Other System Value Value and Format: Must comply with specifications in NIST-2011.

- If this field is present, Geographic Coordinate Other System Identifier must be present and populated.


15.999

Palmprint Image


Source: Generated

Required: In accordance with the following:

All palm positions must be accounted for (two positions for full palms or four positions for upper/lower palm pairs) so there must be a record for each position.


Occurrences: 1


- The FBI EBTS specifies a nominal compression ratio of 15:1. Therefore, the following computation should result in a value of approximately 15:

Horizontal Line Length x Vertical Line Length --------------------------------------------------------------

length of this image data field

- The minimum size is 5,000 bytes and the maximum size is 2,000,000 bytes.


A.6 Annotations for Fingerprints in Field 2.084 and for Palm Prints in Field 15.018

For fingers, according to the FBI EBTS Spec (pg C-3):

"A partially amputated finger should be printed and be marked amputated, XX. If the finger’s image is missing for any reason, (for example, when the arresting agency did not specify a reason in its submission to the State Identification Bureau) the UP code should be used. This field is used to tell the AFIS which finger positions need to characterized. The UP code should only be used when the entire image is not provided for fingerprints in the submission. This code will indicate that the AFIS matcher should ignore this image and not include the image in the matching process."

Therefore:

If a finger is partially amputated and a partial fingerprint (distal) impression can be captured: Capture the impression and also set the annotation 2.084 Amputated or Bandaged Code to 'XX' to indicate a partial amputation.

If a finger (distal) cannot be captured: Supply only the annotation by setting 2.084 Amputated and Bandaged to 'UP' to indicate that a fingerprint impression cannot be captured (is unprintable).

For palm prints, according to ANSI/NIST standard (pg 385) as referenced by FBI EBTS Spec (Appx Q):

"XX shall be used only when a partial print exists due to amputation; therefore it contains some friction ridge detail. UP shall be used with the complete block where an image was to be transmitted, but there is no image due to amputation or total lack of friction ridge detail (such as with a bandage). An image with a scar should not be marked XX or UP."

Therefore:

If the palm position is partially amputated and a partial impression can be captured: Capture the impression and also set the annotation 15.018 Amputated or Bandaged Code to 'XX' to indicate a partial amputation.

If the entire palm position cannot be captured: Supply only the annotation by setting the 15.018 Amputated or Bandaged to 'UP' to indicate that the palm impression cannot be captured (is unprintable).

FINGERS FINGERS FINGERS PALMS PALMS PALMS

Amp/Band Code 2.084 in Type 2 record

Type 4 record with finger image

** Amp/Band Code 15.018

in Type 15 record

Palm image in Type 15 record

Fingertip is amputated (part of distal above 1st joint is present)

XX image Part of upper palm is amputated

XX image

Entire distal above 1st joint is amputated

UP no record Entire upper palm amputated

UP no image

Distal is unprintable for any other reason (e.g., bandaged)

UP no record Entire upper palm is unprintable (e.g., bandaged)

UP no image

** Same rules apply to lower palm.


APPENDIX B ANSI/NIST TRANSACTION FORMAT

This appendix describes some key elements of the transaction record format as implemented in MCHS.

To correctly format an MCHS tenprint transaction, both the requirements of this ICD and the ANSI/NIST-ITL 1-2011 transmission format standard must be followed. If there is a conflict between the ANSI/NIST standard and this ICD, this ICD takes precedence.

MCHS uses five of the record types that are documented in the ANSI/NIST transmission format standard:

Record Type

Record Name

Record Format

Contents

1 Transaction Information Tagged text Required.

Information about the overall transaction file including an index to the other records in the file

2 Tenprint Data Tagged text Required.

MCHS-defined text record; used in MCHS for demographic and other textual data associated with the fingerprint data; the contents of this record depend of the type of transaction

4 High-resolution Grayscale Fingerprint Image

Binary Required.

High-resolution grayscale image of fingerprint(s)

10 Facial and SMT Image (future) Tagged text with binary

Optional in ARRs and DOCs.

Image of face and related textual information

- or -

Image of scar, mark, or tattoo and related textual information

15 Variable-resolution Palm Print Image

Tagged text with binary

Optional in ARRs and DOCs.

Image of palm print and related textual information

Three different record formats are used.

Tagged text records use a tagged structure of fields, subfields, and information items containing text values. Tags are present only if there is data for the field.

Tagged text with binary records use a tagged structure like the tagged text records and the last field in the record contains binary image data.

Binary records use a fixed position field structure and include binary image data.

Structure requirements for the tagged text record format are described in Appendix B.1; requirements for the tagged text with binary record format are described in Section B.2; requirements for the binary record format are described in Section B.3; and requirements for setting the IDC values in the Type 1 record.

All records begin with a length field that gives the length of the record including the length field itself and all separators. The format of the length field varies depending on whether the record is a tagged text or binary format. For tagged text record format (Types 1 and 2) and tagged text with binary record format (Types 10 and 15) the length is included in a tagged field as described in Appendix B.1. For binary record format (Type 4), the length is a 4-byte binary value in network byte order (i.e., most significant byte first).

Samples of each record type are found in Appendices G and H.


B.1 Tagged Text Record Format

Data fields in tagged text record format have the following format

<record type>.<field number>:<field value>G

S

where G

S is a group separator character, ASCII value hexadecimal '1d'. The tag is the leading part through the colon character. The <record type> is record type number and the <field number> is a two or three digit field number. For record type 1, the <field number> must be a two-digit number and for record type 2, <field number> must be a three-digit number with leading zeroes. The tag is followed by the field

data and concludes with the G

S separator character. An example, using field 1.04 type of transaction in the Type 1, is

1.04:ARRG

S

The last field of the record is terminated by an FS character, ASCII value hexadecimal '1c' instead of a

GS.

There are four different structures that can make up the <field value>, depending on the field type. The field types and required formats are documented in the table below. The term "element" is used when each position represents a different type of information - e.g., 2.067 Image Capture Equipment is a group non-repeating field with three elements - make, model, and serial number - versus multiple values for the same type of information.

Field Type Format and Example Comments

Simple non-repeating

<value> G

S No internal separators.

2.020:MEG

S Example: 2.020, Place of Birth

Simple repeating <value1>RS<value2>

RS…<valuen>

GS or

<value1>US<value2>

US…<valuen>

GS

Internal separators may be either RS or

US but

within a field, all must be the same. There are a variable number of <values>.

2.016:555555555RS585001234

RS477001234

GS Example: 2.016, Social Security #

Group non-repeating

<element1>RS<element2>

RS…<elementn>

GS or

<element1>US<element2>

US…<elementn>

GS

Separators between elements in the group may be either

RS or

US - however, within a field, all

separators must be the same. There are a fixed number of <elements> and all separators must appear, even if the element values are null.

2.039:ConstructionRSReynolds Corp

RS

RS

RSRockland, MS

GS Example: 2.039, Employment

Group repeating <element11>US<element12>

US…<element1n>

RS

<element21>US<element22>

US…<element2n>

RS

<elementm1>US<elementm2>

US…<elementmn>

GS

US separators occur between elements in an

occurrence of the group and RS characters

separate group occurrences. . There are a fixed number of <elements> and all separators must appear, even if the element values are null.

2.017:Natl Agency NrUS12-X45

RSUSAF Serial Nr

US34567

GS Example: 2.017, Misc Id #

Additional rules that must be followed when creating a tagged text record format include:

1. Fields must appear in ascending order by field number.

2. If a field contains no data, the tag and separator characters for the field must not be included in the record.


B.2 Tagged Text with Binary Record Format

Tagged text with binary records contain all of the field types and must conform to all of the rules described in Section B.1. For record types 10 and 15, <field number> must be a three-digit number with leading zeroes.

This record format contains one additional field type, as described below:

Field Type Format and Example Comments

Image <field data>FS Must conform to NIST-2011 image specifications.

10.999:<binary image data>FS Example: 10.999, Facial or SMT Image

That binary image data does not require any special handling. It may contain values equivalent to the record separators described in Section B.1 but since this is the last field in the record, it is not necessary to give them any special treatment such as escaping them. The field must, however, must conclude with the

record terminator FS.

B.3 Binary Record Format

Rules that must be followed when creating a binary record format include:

1. Records with a binary layout have a fixed layout of data without any separators or tags.

2. Data that represents a numeric quantity of greater than one byte in length (e.g. the length field) is stored in network byte order.

3. Fields must appear in the order specified.

4. Fields must be the length specified.

B.4 IDC Field Values

Each record other than the Type 1 must have a unique id number called an Information Designation Character (IDC) assigned to it. It uniquely identifies each record within the transaction. The IDC numbers must be sequential, beginning with 0, with no gaps. In Types 2, 10, and 15 the ICD is recorded in field <record type>.002. In Type 4, the ICD is recorded in byte 5.

The records, identified by their IDC, are indexed in the Type 1 in field 1.03 File Content.

The records must appear in the transaction in ascending IDC sequence.


APPENDIX C TRANSACTIONS SENT BY A SCANNING STATION TO MCHS

Appendix C.1 describes the requirements for a scanning station to send tenprint transactions to MCHS via SMTPS email. Appendix C.2 describes the requirements for some existing scanning stations that use SMTP.

C.1 SMTPS Mail Processing Requirements

A scanning station must use Simple Mail Transfer Protocol Secure (SMTPS) to send tenprint transactions to MCHS. See the reference documents for more details regarding the SMTPS protocol and the format of messages. If there are conflicts between the requirements in this appendix and the referenced RFCs, the information in this appendix takes precedence over information in the referenced documents.

The SMTPS protocol is based on the SMTP protocol but is carried over an SSL/TLS secure connection.

Scanning stations using SMTPS protocol connect to host mscjis.dps.ms.gov over port 465. Once the SSL/TLS connection is established, normal SMTP exchanges are used.

A scanning station's email address is from_station/[email protected] where from_station/operator_id is the station id assigned by the CIC. This is the same scanning station id that is in the TCN field.

Email messages consist of two parts: a header and a body. The two parts are separated by a null line indicated by the four ASCII control characters for the sequence 'CR, LF, CR, LF'. The header contains routing and control information about the message and the body contains the message itself. The character case of the initial keyword in each line of the message header is allowed by the standards to be case insensitive. Thus, "FROM:", "from:", "From:", and "FrOm:" are all allowable.

A scanning station may send other header lines than those listed in the remainder of this appendix such as Date:, CC:, or BCC:. MCHS ignores these additional header lines. Furthermore, MCHS does not depend on the order of lines in the message header as long as the required lines are present.

The approach used by MCHS is very similar to that used to send transactions to the FBI/NGI system. One area of difference is in the content of the subject line of the email - MCHS has specific requirements as described below.

Message Header

The email message header must contain the following header lines.

Header Line Notes

To: <[email protected]>

-- or --

To: name <[email protected]>

Note the angle brackets are part of the syntax around the email address.

A descriptive name may be included as in

To: MCHS Controller <[email protected]>

From: from_station/operator_id

-- or --

From: from_station/operator_id @mscjis.dps.ms.gov

-- or --

From: station-name < from_station/operator_id @mscjis.dps.ms.gov>

This contains the scanning station id (station_id) as assigned by the CIC.

The email address may or may not contain an @ sign followed by a host name.


May also include a descriptive name as in

From: River County SO <[email protected]>

Subject: subject_line As described below

Content-type: application/octet-stream Must be present. See discussion below under "Message Body".

Content-transfer-encoding: Base64 Must be present. See discussion below under "Message Body".

Other leader lines may be included but will be ignored by MCHS.

Each email message must have a subject line in this format:

<TOT>; <Unique ID#>; <Last Name>, <First Name>; <DOB>; <C/L>

The fields in the subject line are separated by semi-colons ";" except for the Last Name, which is followed by a comma. The semi-colons and comma may be followed by a space character.


The fields in the subject line are defined in the table below.

Field Length Value Notes

TOT 3 Type of transaction: ARR, APP, or DOC (the same value as in field 1.04 Type of Transaction)

Must be upper case; followed by a semi-colon

Unique ID Number

up to 12 For APP transactions, Applicant Agency ORI (the same value as in field 1.08 Arrest/Applicant/DOC Agency ORI)

For ARR transactions, the Arrest Tracking Number (the same as field 2.701 Arrest Tracking Number)

For DOC transactions, the Department of Corrections Number (this is the same as field 2.709 DOC Number)

Followed by a semi-colon

Last Name up to 35 Subject's last name (the same value as in the Last Name of the first occurrence of field 2.018 Name)

Followed by a comma and a space

First Name up to 20 Subject's first name (the same value as in the First Name of the first occurrence of field 2.018 Name)

Followed by a semi-colon

DOB 8 Subject's date of birth (the same value as in the first occurrence of field 2.022 Date of Birth)

Must be in format CCYYMMDD; followed by a semi-colon

C/L 1 C or L "C" = not used

"L" = always specify "L"

An example of the subject line of an ARR arrest fingerprint transaction is shown below:

ARR; 8897000000; BOND, JAMES; 19470805; L

where 8897000000 is the arrest tracking number.

Message Body

The Message Body contains the NIST transaction in the body itself. The transaction must be in the body of the email itself. It cannot be an attachment. MCHS will not accept transactions sent as attachments.

The content type of the body must be binary data type of 'application/octet-stream' and it must be encoded as 'Base64'.

Base 64 is used for sending binary data in an email message body because some email exchangers transform message bodies by altering line terminations1 or break long lines into short ones. To protect the NIST fingerprint transaction, binary data is encoded as a series of short lines consisting of only printable ASCII characters. The scheme adopted by MIME RFCs 2045-2047, known as base 64 encoding, transforms 3 binary bytes (24 bits) into four printable ASCII characters from a set of 642. The base 64 characters are placed in lines of approximately 64 characters. Line terminations are ignored by software when the base 64 encoded transaction is converted back into its binary form. If the NIST transaction is not a multiple of three bytes, there is a special method to encode the fact. (See footnotes at the bottom of this page.)

Example

Samples of transactions are shown in Appendix G.

1 Mail exchangers typically convert line terminations to match the conventions of the system on which the email exchanger is running. Lines are terminated in Linux with a newline (NL) control character. They are terminated with a carriage return (CR) control character under MacOS. The various Windows operating systems terminate lines with a CR followed by a NL.

2 The 64 characters are A through Z, a through z, 0 through 9, + and /. These characters can be thought of as "digits" in base 64, hence the name. The equals sign is used to indicate a file that is not a multiple of three bytes in length. See RFC 2045.


C.2 Legacy SMTP Mail Processing

Some existing stations use Simple Mail Transfer Protocol Secure (SMTP) to send tenprint transactions to MCHS.

For these existing stations, requirements are the same as described in C.1 with the following differences: (1) substitute all occurrences of SMTPS with SMTP, (2) scanning stations using SMTP protocol connect to

host mscjis.mchs.state.ms.us over port 25, and (3) in the message header To line, replace

<[email protected]> with <[email protected]>.


APPENDIX D RESPONSES FROM MCHS TO A SCANNING STATION

MCHS sends a variety of transaction response messages to the scanning stations. These are described in Section 4.2.

Appendix D.1 describes the requirements for a scanning station to retrieve and process all messages sent to a scanning stations POP3 mail. Appendix D.2 describes the requirements for some existing scanning stations that use POP3.

Appendix D.3 describes the MS Search Response, Prosecutor and Court Disposition Forms, and DNA Database Collection Form, and Record Under Review Notice; Appendix D.4 describes MCHS Reject Notices; Appendix D.5 describes the MCHS Warning Notice; and Appendix D.6 describes the FBI Search Response and FBI Error Response.

D.1 POP3S Mail Processing Requirements

A scanning station must use Post Office Protocol Version 3 Secure (POP3S) to retrieve these responses from MCHS. See the reference documents for more details regarding the POP3S protocol and the format of messages. If there are conflicts between the requirements in this appendix and the referenced RFCs, the information in this appendix takes precedence over information in the referenced documents.

The POP3S protocol is based on the POP3 protocol but is carried over an SSL/TLS secure connection.

Scanning stations using POP3S protocol connect to host mscjis.dps.ms.gov over port 995. Once the SSL/TLS connection is established, normal POP3 exchanges are used.

A scanning station's email address is [email protected] where station id is the scanning station id assigned by the CIC. This is the same scanning station id that is used in the TCN field.

The POP3S protocol requires a login as part of the session. The login id is the station_id.

Email messages consist of two parts: a header and a body. The two parts are separated by a null line indicated by the four ASCII control characters for the sequence 'CR, LF, CR, LF'. The header contains routing and control information about the message and the body contains the message itself. The character case of the initial keyword in each line of the message header is allowed by the standards to be case insensitive. Thus, "FROM:", "from:", "From:", and "FrOm:" are all allowable.

The subject line is always provided in messages sent to the scanning station from MCHS so that scanning station software can easily and reliably determine the proper handling of each incoming message.

MCHS may send other header lines than those listed in the remainder of this appendix such as Date:, CC:, or BCC:. These can be ignored by the scanning station.

The scanning station must retrieve any and all messages that are sent to its POP3 mail, even if it is a message that is not described in Appendices D and E. The station's processing of responses and unrecognized messages sent to its POP3 mail must include the following:

The scanning station must automatically delete all types of messages from the station's POP3 mail file on the MCHS server. The CIC prefers that the scanning station retrieve all messages and delete them on the same day that MCHS sends them. The CIC sets a maximum number of days that messages can remain in the POP3 mail file. Currently, the maximum is 30 days; however, the CIC may change the maximum. Therefore, the maximum number of days must be configurable. (Deleting POP3 mail messages is generally done using the POP3 mail delete command 'DELE'.)

The scanning station must be able to print any and all transaction response messages. The entire email message, including the email header lines, must be printed.

If the scanning station is configured to automatically print transaction responses, it must also print any unexpected message in its entirety if it is less than 300 lines in length (including header lines) and only the first 300 lines otherwise.


D.2 Legacy POP3 Mail Processing

Some existing stations use Post Office Protocol Version 3 (POP3) to send tenprint transactions to MCHS.

For these existing stations, requirements are the same as described in D.1 with the following differences: (1) substitute all occurrences of POP3S with POP3, and (2) scanning stations using POP3 protocol connect

to host mscjis.mchs.state.ms.us over port 110.


D.3 MS Search Response, Prosecutor and Court Disposition Forms, DNA Database Collection Form, and Record Under Review Notice

The responses to an arrest, applicant, or DOC transaction in MCHS include an MS Search Response (a rap sheet or a no record response). Arrest transactions also produce Prosecutor and Court Disposition Forms and, under certain conditions, also produce a DNA Database Collection Form and/or a Record Under Review Notice. All of these responses are sent to the scanning station that submitted the arrest or applicant transaction.

Each of these responses is sent in a separate email. See Section 7.0 for information on how to identify each type of message.

Message Header

Some of the header lines included in the email message header are listed below.

Header Line Notes

To: station-id

-- or --

To: [email protected]

-- or --

To: station-name <[email protected]>





To: River County SO <[email protected]>

From: "MCHS" <[email protected]> Note the angle brackets are part of the syntax around the email address.

Subject: original transaction subject line This is the same subject line as in the transaction sent to MCHS by the scanning station.

Content-type: text/plain

Content-transfer-encoding: 7bit

The message header must be included when the transaction responses are printed.

Message Body

All Mississippi transaction responses begin with a short header that indicates the response type, the subject name, and handling information for the scanning station operator. Examples of all of these responses are shown below.

Print/Display

Each of these responses must be printed/displayed by the scanning station using a fixed-space font so that the data is properly aligned.


Example: an MS Rap Sheet

From [email protected] Mon Sep 01 10:24:15 CDT 2014

... ...

Date: Mon, 01 Sep 2014 10:24:15 -0500 (CDT)

Message-Id: <[email protected]>

... ...

From: "MCHS" <[email protected]> To: Smallville <ls990001>

Subject: ARR;9010000009;BOND, JAMES;19481129;L

... ...

Content-Type: text/plain

Content-Transfer-Encoding: 7bit

Mississippi Criminal History System

Mississippi Rap Sheet for arrest transaction

Subject Name: BOND, JAMES

Transaction Control Number: lstest1-20030214-0001

Handling Information (MS ARR-Oth3 OthEm/AgyNo):

This is an original copy for the arrest agency.

Mississippi Criminal History Record

Information on file as of SEPTEMBER 1, 2014

1. INTRODUCTION

This record contains information contained in the criminal history file

of Mississippi Department of Public Safety on the date it was prepared;

if information is needed later, a new inquiry should be made. This

information is based on fingerprint identification.

If the request for this information did not include fingerprints, this

record may not describe the subject of the inquiry.

There may be further information concerning this subject in local files.

Use of this information is subject to state and federal law and is

limited to the purpose stated in the inquiry. Misuse is subject to

criminal and civil penalty.

Offenses are marked as felonies, misdemeanors or violations in

accordance with Mississippi law.

... ...

3. IDENTIFICATION DATA

NAME

BOND, JAMES ALBERT

BOND, JAMES

... ...


Example: an MS Court Disposition Form


... ...

Date: Mon, 01 Sep 2014 10:24:15 -0500 (CDT)


... ...



... ...




COURT Disposition Form

Arrest Tracking Number: 880000001X

Name: BOND, JAMES, ,

Date of Birth (yyyymmdd): 19800831 Sex: Male Race: White

Arrest Agency: MS0000000 - Mainsville PD

Arrest Date (yyyymmdd): 20030111 Arrest Case Number: N/A

Arrest Charges:

Statute Description Counts Severity Date

97-1-1 Conspiracy 1 Felony 20030110

... ...


Example: an MS DNA Database Collection Form


... ...

Date: Mon, 01 Sep 2014 10:24:15 -0500 (CDT)


... ...



... ...




DNA Database Collection Form

State ID (SID): MS00000000 ATN: 880000001X

*****************************************************************

* FOR CRIME LAB USE ONLY

* Sample Received by: ___________________________

* Date: ____________

* MCL No. _________________________

*****************************************************************

Name: BOND, JAMES, , III

... ...

Example: a Record Under Review Notice


... ...

Date: Mon, 01 Sep 2014 10:24:15 -0500 (CDT)


... ...

From: "MCHS" <[email protected]>

To: Smallville <ls990001>

Subject: ARR; 8800000010; POTTER, ALBERT; 19800831; L

... ...




=== RECORD UNDER REVIEW ===

Regarding your transaction lstest1-20030214-1234

Subject Name: BOND, JAMES

Date of Birth: 19481129

Arrest Tracking Number: 1111111111

Received by MCHS on 20140901 09:34:56

The criminal history for the subject individual (SID MS00000000

is under review and will be forwarded to you within 24 hours.


D.4 MCHS Reject Notice

If a transaction sent to MCHS by a scanning station contains uncorrectable errors, a reject notice is generated and sent back to the scanning station. The transaction is not processed further and so it must be corrected and resubmitted by the scanning station operator.

Message Header


Header Line Notes

To: station-id

-- or --


-- or --

To: station-name <station [email protected]>





To: River County SO

<[email protected]>

From: MCHS Prescreening <[email protected]>

-- or --

From: MCHS Postscreening <[email protected]>


Subject: Reject: original transaction subject line This contains the subject line information from the submitted transaction.



Message Body

The message body contains the MCHS Reject Notice. It lists general information about the transaction followed by a listing of uncorrectable errors.

The error messages that will appear in a reject notice if the transaction is not compliant with this ICD are found in the MCHS Reject Notice and Warning Notice Error Messages document.

If an uncorrectable error is in a field with multiple occurrences, the occurrence number with the uncorrectable error is listed. The first occurrence is occurrence 1.

Print/Display

This response must be printed/displayed by the scanning station using a fixed-space font so that the data is properly aligned.


Example 1: An annotated example of the Transaction Reject Notice due to errors other than problems with fingerprints is shown on the following page.


... ...

Date: Mon, 01 Sep 2002 10:24:15 -0500 (CDT)


... ...

From: MCHS Prescreening <[email protected]>

To: CLARKSDALE PD <ls140123>

Subject: ARR;123456789X;SMITH, JOHN;19650215;L (1st & 2nd fields vary by TOT) ... ...



MISSISSIPPI CRIMINAL HISTORY SYSTEM

TRANSACTION REJECT NOTICE

Type of Transaction: Applicant -or- Arrest -or- DOC Subject Name: SMITH, JOHN

Subject Date of Birth: 19650215

Transmitting Agency (from TCN): MS0140123 - CLARKSDALE PD

Station/Operator Id (Email "From"): ls140123 - CLARKSDALE PD LS 1

Station Id From TCN:

Station Location and Type:

ls140123 - CLARKSDALE PD LS 1

Local Agency Livescan

Station Vendor:

Transaction Control Number:

Moore Biometrics

ls140123-20020901-0001

Arrest Agency: (ARR only) -or-

Applicant Agency: (APP only) -or-

DOC Agency: (DOC only)

MS0000001 - FULLER PD

Print Agency: MS0140123 - CLARKSDALE PD

Date Transaction Created: 20020901

Received at MCHS Prescreening: 20020901 10:40

Version Number: 0502

Equipment: Scanners Inc JS-920 112-346

Originating Agency Case Number:

(ARR and APP only) (only if populated)

2002-16329F

Arrest Tracking Number: (ARR only) 125356789X

Highest Severity: (ARR only) Felony

Reason Fingerprinted: (APP only) Gaming App 75-76-33

DOC Number: (DOC only) DOC12345

V - Vendor software or configuration errors

FIELD/VALUE IDC OCC PROBLEM

Social Security # 1

'111111111'

V511 Invalid field value

Hair Color 'Blueberry' V701 Value not on MCHS edit table

Hair Color

Further information about messages listed above is found in the MCHS

Tenprint Transaction Reject Notice and Warning Notice Error Messages

document.

The information at the beginning of the Reject Notice identifies the transaction. The following is additional information about some of the fields:

"Transmitting Agency (from TCN)" and "Station Location and Type" are based on the station id in the TCN. (See TCN in Appendix A.1).


"Station/Operator Id (Email "From")" is the station id that was in the email From line. (See Appendix C.)

"Station/Operator Id (Email "From")" and "Station Id From TCN" must always be the same. If they are not, there will be an error message indicating this problem.

"Arrest Agency" is from field 1.08 Arrest Agency ORI in the Type 1 record. Fields 1.08 and 2.702 Arrest Agency must always be the same. If not, an error message will indicate this problem.

"Highest Severity" indicates the highest severity specified in the arrest charges.

If there is a problem with the Type 1 record such that it cannot be parsed, some information that is normally in the Reject Notice cannot be included and is indicated by Unknown or Unavailable.

.If there is no value in the optional fields, the line is not included.

The errors that caused the transaction to be rejected are listed below the column headings "FIELD/VALUE IDC OCC PROBLEM".

The error messages are described in the Reject Notice and Warning Notice Error Messages document..

If the value in error is in a repeating field, the occurrence ("OCC") is included. The OCC field identifies the occurrence within a field that may have multiple values (e.g., more than one SMT may be entered). The OCC is specified in the "OCC" column.

If the error is about a specific Type 4, 10 or 15 record, the IDC value is included. The IDC identifies the specific record within the transaction that has the error. The IDC value is specified in the "IDC" column. This will be useful information for a vendor.


Example 2: an MCHS Reject Notice for an ARR due to problems with fingerprints (rejected by AFIS)


... ...

Date: Mon, 01 Sep 2014 10:24:15 -0500 (CDT)


... ...

From: MCHS Prescreening <[email protected]> To: SMALLVILLE SO <ls990001>

Subject: ARR;9010000009;POTTER, HARRY;19900315;L

... ...



MISSISSIPPI CRIMINAL HISTORY SYSTEM

TRANSACTION REJECT NOTICE

Type of Transaction: Arrest

Subject Name: POTTER,HARRY

Subject Date of Birth: 19900315

Transmitting Agency (from TCN): MS0000000 - SMALLVILLE SO

Station/Operator Id (Email "From"): ls990001 - SMALLVILLE SO LIVESCAN 1

Station Id From TCN: ls990001 - SMALLVILLE SO LIVESCAN 1

Station Location and Type: Local Agency Livescan

Station Vendor: Concord Inc

Transaction Control Number: ls990001-20140901-1234

Arrest Agency: MS0990000 - SMALLVILLE PD

Print Agency: MS0000000 - SMALLVILLE SO

Date Transaction Created: 20140901

Arrest Tracking Number: 9010000009

Highest Severity: Felony

Archive ID: 9999999

Transaction Entered Workflow: 20140901 14:14

Transaction Completed Workflow: 20140901 14:45

Your transaction was canceled with the message '<afis error message>'.

Please retake the fingerprints and resubmit the transaction.


D.5 MCHS Warning Notice

TYPE 10 RECORDS ARE NOT CURRENTLY ALLOWED

If a transaction sent to MCHS by a scanning station contains Type 10 or Type 15 records with uncorrectable errors, a warning notice is generated and sent back to the scanning station.

If the Type 1, Type 2, and Type 4 records did not have errors, the transaction will be processed and the Type 10 and Type 15 records cannot be resubmitted. This warning notice advises submitter of problems that need to be addressed so that future facial image records, SMT image records, and palm print image records are successfully submitted and processed.

If the Type 1, Type 2, or Type 4 records also had uncorrectable errors, MCHS will also send an MCHS Reject Notice and the transaction will not be processed. The Type 10 and Type 15 errors can be corrected and resubmitted when the Type 1, 2 and 4 errors are corrected and resubmitted.

Message Header

The email message header is the same as the header for the MCHS Reject Notice, as shown in D.3, except the subject line is as follows.

Header Line Notes

Subject: Warning: original transaction subject line This contains the subject line information from the submitted transaction.

Message Body

The message body contains the MCHS Transaction Warning Notice. It is identical to the MCHS Reject Notice, as shown in Example 1 in D.4. It lists only errors in the Type 10 and Type 15 records.

The error messages that will appear in a warning notice if the transaction is not compliant with this ICD are found in the MCHS Reject Notice and Warning Notice Error Messages document.

Print/Display

This response must be printed/displayed by the scanning station using a fixed-space font so that the data is properly aligned.


D.6 FBI Search Response and FBI Error Response

When transactions complete their processing at MCHS, many are reformatted and sent to the FBI/NGI system for additional processing. The results of processing at FBI/NGI are received by MCHS and then sent by MCHS to the scanning station in one of these messages.

Message Header


Header Line Notes

To: station-id

-- or --


-- or --

To: station-name <station [email protected]>







Subject: FBI Response for last name,first name The subject name is the same as given in the original transaction sent to MCHS.



The following is an example:


... ...

Date: Mon, 01 Sep 2014 13:12:25 -0500 (CDT)


... ...

From: "MCHS" <[email protected]> To: River County SO <[email protected]>

Subject: FBI Response for POTTER, HAROLD

... ...



The message header must be included when the transaction responses are printed.

Message Body

All FBI transaction responses begin with a short header that indicates the response type, the subject name, and handling information for the scanning station operator. Examples of these responses are shown on the following pages.

Print/Display

Each of these responses must be printed/displayed by the scanning station using a fixed-space font so that the data is properly aligned.


Example: an FBI Search Response to an APP, ARR, or DOC if FBI Record is not found

Note the annotations in angle brackets.


FBI Rap Sheet (SRE) for applicant transaction

Subject Name: POTTER, HAROLD


Handling Information (FBI APP-Oth3 OthEm/AgyNo):

This is an original copy for the applicant agency.

**************************************************

** FBI Response for APP Transaction **

**************************************************

** **

** Type of Submission: APP **

** Type of Response: SRE **

** Archive ID: 9000000 **

** SID: MS0000017X ** <if APP: only if found on MCHS> ** Date Submitted: 20140901 **

** Response Received: 20140901 **

** FBI Response TCN: E20130901000000139999 **

** **

**************************************************

**************************************************

** **

** No FBI Record Found **

** **

**************************************************

Originating Agency Case Number: 111-01 <APP/ARR only; only if in APP/ARR>

State ID Number: MS000000X <ARR only> Name: POTTER,HAROLD CODSWALLOP <from APP/ARR/DOC>

Employer and Address: ACME, 123 Main St, Rose, TX <APP/ARR only; only if in APP/ARR> Occupation: Driver <APP/ARR only; only if in APP/ARR>

Residence of Person Fingerprinted: 999 Main St, Rose, TX <APP/ARR only; only if in APP/ARR> Controlling Agency ID: MS000000Z

Search Results Findings: N

Treat as Adult: Y <ARR only; only if in ARR>

Message: M0111-Another message from the FBI <only if there is a value> <can be up to 11 messages>

Electronic Rap Sheet: (Identity History Summary)

CIVIL APPLICANT RESPONSE <APP only>

NCN E20130901000000139999 CIDN OCA <if APP>

FBI UCN 555222WS0 SID MS0000000X OCA 1111 <if ARR> ... ...

A SEARCH OF THE FINGERPRINTS ON THE ABOVE

INDIVIDUAL HAS REVEALED NO PRIOR ARREST

DATA. CJIS DIVISION

... ...

End of FBI Rap Sheet


Example: an FBI Search Response to an APP, ARR, or DOC if an FBI Record is found

The sample is shown on the next page. Note the annotations in angle brackets.

The content and format of the Electronic Rap Sheet will vary.

If the response is for an APP, the following will appear above the asterisk boxes:

<<<< ATTENTION >>>>

<<<< ATTENTION >>>>

<<<< ATTENTION >>>>

Hit received for Applicant



FBI Rap Sheet (SRE) for applicant transaction




This is an original copy for the arrest agency.

**************************************************

** FBI Response for APP Transaction **

**************************************************

** **


** Type of Response: SRE **

** Archive ID: 9000000 **




** **

**************************************************

**************************************************

** **

** FBI Record Found **

** Rep Sheet Printed Below **

** **

**************************************************

Originating Agency Case Number: 111-01 <APP/ARR only; only if in APP/ARR> FBI Number/UCN: 1234FFBI9

State ID Number: MS000000X <ARR only> Name: POTTER,HAROLD CODSWALLOP <FBI Master Name>

Employer and Address: ACME, 123 Main St, Rose, TX <APP/ARR only; only if in APP/ARR> Occupation: Driver <APP/ARR only; only if in APP/ARR>

Residence of Person Fingerprinted: 999 Main St, Rose, TX <APP/ARR only; only if in APP/ARR> Controlling Agency ID: MS000000Z

Submitted Name: POTTER,HARRY <only if different than FBI Master Name> Search Results Findings: N

Treat as Adult: Y <ARR only; only if in ARR>

Message: M0111-Another message from the FBI <only if there is a value> <can be up to 11 messages>

Electronic Rap Sheet: (Identity History Summary)

UNITED STATES DEPARTMENT OF JUSTICE

... ...

MS000000Z NCN E20130901000000139999

TCN 0009000000

... ...

End of FBI Rap Sheet


Example: an FBI Error Response to and APP, ARR, or DOC

Note the annotations in angle brackets.

The most common causes of error responses are poor quality fingerprints and mislabeled fingers.


FBI Error Report (ERRT) for applicant transaction




This is an original copy for the applicant agency.

<<<< ATTENTION >>>>

<<<< ATTENTION >>>>

<<<< ATTENTION >>>>

ERR/ERRT received

**************************************************

** FBI Response for Applicant Transaction **

**************************************************

** **


** Type of Response: ERR **

** Archive ID: 9000001 **




** **

**************************************************

Originating Agency Case Number: 111-01 <APP/ARR only; only if in APP/ARR> State ID Number: MS000000X <ARR only> Controlling Agency ID: MS000000Z

MESSAGE IS:

L0008 - The quality of the characteristics is too low to be used .

... ...

End of FBI Error Report


APPENDIX E ADMIN MESSAGES FROM MCHS TO A SCANNING STATION

MCHS sends the two administrative messages described in Section 4.3.

A scanning station must use the Post Office Protocol Version 3 (POP3S) to retrieve the messages from MCHS. See the reference documents for more details regarding the POP3S protocol and the format of messages. There should not be any conflict between the requirements in this appendix and the referenced RFCs but, in case of a conflict, the information in this appendix takes precedence over information in the referenced documents.

The POP3S protocol is based on the POP3 protocol but is carried over an SSL/TLS secure connection.

Scanning stations using POP3S protocol must connect to host mscjis.dps.ms.gov over port 995. Once the SSL/TLS connection is established, normal POP3 exchanges are used.

A scanning station's email address is [email protected] where station id is the scanning station id assigned by the CIC. This is the same scanning station id that is used in the TCN field.

The POP3S protocol requires a login as part of the session. The login id is the station_id.

Email messages consist of two parts: a header and a body. The two parts are separated by a null line indicated by the four ASCII control characters for the sequence 'CR, LF, CR, LF'. The header contains routing and control information about the message and the body contains the message itself. The character case of the initial keyword in each line of the message header is allowed to vary by Internet standards. Thus "FROM:", "from:", "From:", and "FrOm:" are all allowable.

The subject line is always provided in messages sent to the scanning station from MCHS so that scanning station software can easily and reliably determine how to handle each incoming message.

MCHS may send other header lines than those listed in the remainder of this appendix such as Date:, CC:, or BCC:. These can be ignored by the scanning station.

The scanning station must retrieve any and all messages that are sent to its POP3 mail, even if it is a message that is not described in Appendices D and E. The station's processing of administrative messages sent to its POP3 mail must include the following:

The scanning station must automatically delete all types of messages from the station's POP3 mail file on the MCHS server. The CIC prefers that the scanning station retrieve all messages and delete them on the same day that MCHS sends them. The CIC sets a maximum number of days that messages can remain in the POP3 mail file. Currently, the maximum is 30 days; however, theCIC may change the maximum. Therefore, the maximum number of days must be configurable. (Deleting POP3 mail messages is generally done using the POP3 mail delete command 'DELE'.)


E.1 Edit Table Download Messages

Edit table downloads allow the set of valid values for some fields to be updated automatically at a scanning station whenever they change on the MCHS system. This is particularly important for fields such as state statute citations as new statutes are enacted each year and existing statutes are revised.

The edit tables must be used to populate valid value lists for use by the operator at the scanning station and to validate the transaction before it is sent to MCHS. The table below identifies the edit tables and the fields with which they are to be used. If an edit table is used in a subfield, the group field name is followed by a slash followed by the subfield name.

A scanning station must automatically update its valid value lists, without human intervention, whenever it receives an Edit Table Download message.

If the agency has a front-end application that interfaces to the scanning station (such as a booking system), the other application must not override the content of the downloaded edit tables.

The scanning station operator must not be able to enter any value other than one of the values from the downloaded edit tables.

Edit Table Must be used for the following field(s)

Agency 1.07 Print Agency ORI (for cardscan only)

1.08 Applicant Agency ORI

AMP or BAND Code 2.084 Amputated or Bandaged / Amputated or Bandaged Code

Arrest Type 2.704 Arrest Type

Country 2.021 Country of Citizenship

Correct Agency 1.08 DOC Agency ORI

Enforce Agency 2.702 Arrest Agency ORI

Enforce Event 2.705 Arrest Charge Set / Action

Eye Color 2.031 Eye Color

Hair Color 2.032 Hair Color

This includes the entry 'ZZDoNotUse'.

Misc Number Type 2.017 Miscellaneous Id / Miscellaneous Id Number Type

Name Suffix 2.018 Name / Name Suffix

Place of Birth 2.020 Place of Birth

Race 2.025 Race

Reason Fingerprinted 2.037 Reason Fingerprinted

Used only for Civil Applicant Agency APPs

(Not used for 'Law Enforcement', Instate Inquiry Only' , 'CRIMINAL INQUIRY' or 'Sex Offender Reg')

Severity 2.705 Arrest Charge Set / Severity

Sex 2.024 Sex/Gender

State 2.703 Driver's License / Driver's License State

Statute 2.705 Arrest Charge Set / Citation

The description will contain a vertical bar (|) with a severity after it. This is for informational purposes for the scanning station operator. It is independent of the severity that the operator specifies in 2.705 Arrest Charge Set/Severity. There is no need for the livescan to do anything other than display this information.

For example:

Statute 49-7-31.1 Hunting - unlawful to hunt

deer during gun season without orange vest|Misdemeanor

Statute_CIC 2.705 Arrest Charge Set / Citation (for CIC only)

Suffix 2.018 Name / Suffix

Supplement 2.705 Arrest Charge Set / Supplement

Tattoo 2.026 Scars, Marks, and Tattoos / SMT Code

10.040 NCIC Designation Code

For example:

Tattoo TAT UL ARM Tattoos, Arm, left upper


Edit Table Must be used for the following field(s)

Yes/No 2.035 Palm Prints Available

2.036 Photo Available

Message Header

The email message header contains the following header lines.

Header Line Notes

To: station-id

-- or --


-- or --








Subject: EDT This indicates that the message is an edit table download message.

Content-type: TEXT/PLAIN


Message Body

The message body consists of a series of lines in a fixed format. The lines have a maximum of 172 characters and may be padded on the right end with spaces to this length. The format of each line is

1. A 20 character edit table name. This name may contain multiple words such as 'Eye Color'. 2. A single space. 3. A 30-character value. This may contain one or more words. Leading and trailing spaces must be

removed from these values. Do not change the character case of the values. (The maximum length of the value will not be greater than the maximum length of the field(s) that use the table.)

4. A single space. 5. A 120-character description of the value. This may contain multiple words or may be completely

empty.

All of the values for a given edit table will appear consecutively. The overall message body is very large, approximately 1 million bytes.


Example

The following is an extracted portion of an edit table download message. Note that the first line in the example is not the SMTPS From: line (note the lack of a colon following the word From). The true From: line is the sixth line.

From [email protected] Mon Apr 16 13:12:26 CDT 2001

... ...

Date: Mon, 16 Apr 2001 13:12:25 -0500


... ...

From: "MCHS" <[email protected]> To: scanning station name <[email protected]>

Subject: EDT

... ...

Content-type: TEXT/PLAIN; charset=US-ASCII


Status: RO

Agency MS0010000 ADAMS COUNTY SO

Agency MS0010100 NATCHEZ PD

...

Enforce Agency MSMHP0800 MS H.P. TROOP K - GULFPORT

Enforce Agency MSMHP0900 MS H.P. TROOP M - BROOKHAVEN

Enforce Agency MSMHP1000 DPS FIREARMS PERMIT

Enforce Event Arrest Charge

Enforce Event Charge not forwarded

Enforce Event Citation charge

Enforce Event Indictment charge

Eye Color Black Black

Eye Color Blue Blue

Eye Color Brown Brown

Eye Color Gray Gray

Eye Color Green Green

Eye Color Hazel Hazel

Eye Color Unknown Unknown

Hair Color Bald Bald

Hair Color Black Black

Hair Color Blond Blond or Strawberry

Hair Color Blue Blue

Hair Color Brown Brown

Hair Color Gray Gray or Partially Gray

Hair Color Green Green

Hair Color Orange Orange

Hair Color Pink Pink

Hair Color Purple Purple

Hair Color Red Red or Auburn

Hair Color Sandy Sandy

Hair Color Unknown Unknown

Hair Color ZZDoNotUse <date and time of download>

Misc Number Type Alien Reg Nr Alien Registration Number

Misc Number Type Bureau Fugitive Bureau Fugitive Index Number

...


E.2 ATN Block Messages

Livescans that process arrest transactions must generate arrest tracking numbers (ATNs) that are unique across the MCHS system. To ensure that two different livescans do not inadvertently generate the same ATN, they are managed centrally MCHS by the CIC.

The ATN Block Message was designed so that a livescan station would never be prevented from submitting arrests because its allocated range of ATNs was used up. The concept is as follows.

One ATN Block message contains two blocks of ATN numbers. Each block consists of two numbers - lowest ATN and highest ATN - which identify the range of ATNs included in the block.

The following describes the ATN Block process. It refers to the diagram below.

First ATN Block Message: When a livescan is initially set up, the CIC creates and sends the first ATN Block message. This contains the following:

The "current" block of ATNs - which contains the first block of ATNs that the livescan will use and

A "next" block of ATNs for the livescan to use when ATNs in the "current" block have been used.

The livescan takes an ATN from the "current" block for each ARR transaction that is created. When the last number in the "current" block is used, the livescan software:

Makes the "next" block the livescan's "current" block.

Second ATN Block Message: The CIC receives a notification from MCHS that the livescan is using the Next ATN Block. The CIC creates and sends a second ATN Block message for the livescan. This contains the following:

The "current" block of ATNs - normally this is the same as in the "next" block of the previous ATN Block message and

A "next" block of ATNs for the livescan to use when all ATNs in the "current" block have been used.

When the livescan receives the second ATN Block message, it will take an ATN from the "current" block for each ARR transaction that is created.

Usually the content of the "current" block of ATNs is the same as the "next" block of the previous ATN Block message. However, the CIC may issue a different ATN range in the "current" block of ATNs than what was in the "next" block of the previous ATN Block message.

The livescan must always use the "current" block as soon as it receives the new ATN Block message. If

First ATN Block Message

“Current” ATN Block

500000000 – 500007999

Second ATN Block Message


500011000 – 500015999

Third ATN Block Message


500205000 – 500206999

“Next” ATN Block

500011000 – 500015999


500205000 – 500206999


500727000 – 500729999

Th

ese

No

rma

lly

Ma

tch

Th

ese

No

rma

lly

Ma

tch


the "current" block is the same as the "next" block of the previous ATN Block message, the livescan should continue using the block starting after the last ATN number that the livescan used. If the "current" block is different than the "next" block of the previous ATN Block message, the livescan software should start using ATN numbers at the beginning of the "current" block.

When the last number in the "current" block is used, the livescan software:

Makes the "next" block the livescan's "current" block.

Third ATN Block Message: The CIC receives a notification from MCHS that the livescan is using the Next ATN Block. The CIC creates and sends a third ATN Block message. The message content and process are as described for the second ATN Block Message.

Subsequent ATN Block Messages: The message content and process continue as described for the third ATN Block Message.

Message Header

The email message header must contain the following header lines.

Header Line Notes

To: station-id

-- or --


-- or --







From: mchs <[email protected]> Note the angle brackets are part of the syntax around the email address.

Subject: ATN This indicates that the message is an ATN block message.

Content-type: TEXT/PLAIN


Message Body

The message body consists of four lines, each consisting of a single nine-digit number with the following meanings:

Lowest ATN in the "current" ATN block range

Highest ATN in the "current" ATN block range

Lowest ATN in the "next" ATN block range

Highest ATN in the "next" ATN block

ATNs are consecutive within a range. A range is inclusive of the lowest and highest ATNs in the range.

A check digit must be suffixed (added) to each ATN. The algorithm to determine the check digit is in Appendix F.

Example

The following message shows that the current range of ATNs to be used is from 500000000 through 500007999 and the next range is from 500008000 through 500015999. Note that the first line in the example is not the SMTPS From: line (note the lack of a colon following the word From). The true From: line is the sixth line.


From [email protected] Mon Apr 16 13:29:00 CDT 2001

... ...

Date: Mon, 16 Apr 2001 13:29:00 -0500 (CDT)


... ...

From: "MCHS" <[email protected]> To: scanning station name <ls000000>

Subject: ATN

... ...

Content-type: TEXT/PLAIN; charset=US-ASCII


Status: RO

500000000

500007999

500008000

500015999


APPENDIX F ATN CHECK DIGIT ALGORITHM

The check digit algorithm is applied to the nine digit ATN base of Field 2.701 ATN #. The full ATN is the original nine-digit number from the assigned ATN number range with the check digit appended for a total of 10 characters. The check digit may be 'X' so the resulting ATN must be treated as a character string, not a number.

1. Set sum to 0.

2. Set multiplier to 2.

3. For each digit in number proceeding from right to left loop

4. Increase sum by the product of multiplier and the digit value.

5. Increase multiplier by 1.

6. End loop

7. Set remainder to the integer remainder of sum divided by 11.

8. Set check to 11 minus the remainder.

9. If check is 11 then return 0 as the check digit..

10. If check is 10 then return X as the check digit.

11. Otherwise, return check as the check digit.

Examples of check digit calculations, using a maximum of nine digits, are shown in the table below.

Input String Sum Remainder Check Digit

000000000 0 0 0

111111111 54 10 1

123456789 210 1 X

29725 101 2 9

989064850 337 7 4

889700023 285 10 1

The following listing shows the MCHS implementation of the algorithm for the ATN check digit in an Oracle PL/SQL procedure. It is provided in case it is useful to see an operational implementation. This software will validate check digits ATN fields in ARR transaction sent to MCHS.


/*********************************************************************

* Module: modulus_11

* Created: July 23, 1997

* Description: This function generates the mod-11 check digit from

* a numeric string. It receives a string as input and

* returns a single alpha character. An exception is raised

* if the input string is null or contains a non-numeric

* character. Check digit validation is required for the

* Arrest Tracking Number (ATN). This function

* implements the algorithm used by Moore Business Forms

* to print the MCHS Arrest Fingerprint Cards. That algorithm

* is stated to be the algorithm used by the State of Texas.

*

*********************************************************************/

create or replace function modulus_11 (the_string in varchar2)

return varchar2 is

the_sum number;

the_weight number;

the_length number;

the_digit number;

the_mod number;

the_char char(1);

os number;

null_input EXCEPTION;

non_numeric EXCEPTION;

BEGIN

/*

Obtain the length of the input string and set the position counter

to that value. Initialize the sum to zero and the weight to 2.

*/

the_length := length(the_string);

os := the_length;

the_sum := 0;

the_weight := 2;

/*

If the input string is null, raise an exception and exit.

*/

if the_string is null

then

raise null_input;

end if;

/*

Now start with the rightmost character in the string and loop backwards

through the string, incrementing the sum for each character in the

string.

*/

loop

/*

Begin by converting the current digit to a number. If that conversion

fails, raise an exception and exit.

*/

BEGIN


the_digit := to_number(substr(the_string,os,1),'9');

EXCEPTION

when others then raise non_numeric;

END;

/*

Each digit is multiplied by the position-number, where

the rightmost digit has position number 2. The position-number has been

initialized to 2 and will be incremented for each iteration through the

loop. First, increment the sum by the product of the current digit

and the current position. Then, add 1 to the current weight in

preparation for the next iteration. Then, decrement the position

counter by 1. If the counter is then at zero, then the leftmost digit

has just been processed. Exit the loop without further processing.

*/

the_sum := the_sum + (the_digit * the_weight);

the_weight := the_weight + 1;

os := os - 1;

if os <= 0

then

exit;

end if;

end loop;

/*

Now, divide the sum by 11 and then subtract the remainder from 11.

*/

the_mod := 11 - mod(the_sum,11);

/*

The result of the computation above is table-lookuped to yield the

check character. The use of the SQL decode function requires a select

from DUAL. The I/O involved in this select could be avoided by recoding

this operation as an if .. elsif .. statement, but the overall saving in

I/O would be trivial. Note that this table must contain 11 values

to accommodate the case that the sum is evenly divisible by 11 and the

remainder is thus zero.

*/

select decode(the_mod,1,'1',

2,'2',

3,'3',

4,'4',

5,'5',

6,'6',

7,'7',

8,'8',

9,'9',

10,'X',

11,'0')

into the_char

from dual;

/*

Return the result of the table lookup and exit.

*/

return the_char;

EXCEPTION


when null_input

then

raise_application_error(-20019,'Null value passed to '||

'MODULUS_11 function.');

when non_numeric

then

raise_application_error(-20020,'Non-numeric digit "'||

substr(the_string,os,1)||

'" in input "'||

the_string||'".');

when others

then

raise_application_error(-20021,'Internal error in function '||

'MODULUS_11. '||

'Consult your Oracle DBA.');

END;


APPENDIX G SAMPLE TRANSACTIONS WITH TYPE 1, 2, AND 4 RECORDS

This appendix contains examples of Type 1, Type 2, and Type 4 records in ARR, APP, and DOC transactions. The purpose of the appendix is as an aid to a scanning station vendor in determining whether transactions are being properly formatted in accordance with Appendices A and B and then properly encoded as email messages according to Appendix C.


G.1 Arrest Transaction

A sample of an ARR transaction is shown in this appendix. Appendix G.1.1 lists the contents of the Type 1, Type 2, and Type 4 records of the transaction. The transaction includes 14 Type 4 records, each with an image field, which for sample purposes only, consists of a single zero byte.

Appendix G.1.2 shows the non-binary fields of the transaction defined in G.1.1 in NIST-2011 format, including the record separators.

Appendix G.1.3 shows a complete email message containing the transaction from Appendix G.1.1. The transaction is very short because of the small size of the Type 4 test records. Ordinarily, a transaction with 14 finger print images is more than 650,000 bytes in size before Base64 encoding and 860,000 bytes after encoding.

Field n.01Record Header is calculated by the scanning station software. It is the length of the record, including field n.01, in bytes.

"(no data)" indicates that no data is in the subfield and is therefore null.

G.1.1 ARR Transaction Field Contents

Value

Type 1 Record:

Record Header

1.01 (len)

194 (Calculated)

Version Number

1.02 (ver)

0502

File Contents

1.03 (cnt)

--

First Record Category Code (Record Category Code (0))

1

Content Record Count (Information Designation Character (0))

15

Record Category Code (1) 2

Information Designation Character (1) 0






















Value









Type of Transaction

1.04 (tot)

ARR

Transaction Date

1.05 (dat)

20020405

Print Agency ORI

1.07 (dai)

MS0000000


1.08 (ori)

MS0000000

Transaction Control Number

1.09 (tcn)

ls000000-20150315-0025

Native Scanning Res.

1.11 (nsr)

19.69

Nominal Transmitting Res.

1.12 (ntr)

19.69

Type 2 Record:

Record Header

2.001 (len)

680 (Calculated)


2.002 (idc)

0


2.009

02-123456

Social Security # (0)

2.016

123456789

Social Security # (1)

2.016

987654321

Miscellaneous Id #

2.017

--

Misc Id # Type (0) Natl Agency Nr

Misc Id # Value (0) 12-X45

Name

2.018

--

Last Name (0) POTTER

First Name (0) HAROLD

Middle Name (0) ALBERT

Name Suffix (0) JR

Place of Birth

2.020

YY


2.021

EN

Date of Birth (0)

2.022

19800831

Sex/Gender

2.024

Male


Value

Race

2.025

White

Scars, Marks, and Tattoos

2.026

--

SMT Code (0) SC FHD

SMT Description (0) LIGHTNING BOLT

SMT Code (1) TAT UL ARM

SMT Description (1) Owl

Height

2.027

507

Weight

2.029

130

Eye Color

2.031

Hazel

Hair Color

2.032

Brown

Palm Prints Available

2.035

Yes

Photo Available

2.036

No

Date Printed

2.038

20020405

Employment

2.039

--

Occupation Construction

Employer Name Reynolds Corp.

Employer Address 1 (no data)

Employer Address 2 Suite 45

Employer Address 3 Riverville, MS 22222

Residence

2.041

--

Residence Address 1 200 Side Street

Residence Address 2 Apt. 40

Residence Address 3 Riverville, MS 22225

Date of Arrest

2.045

20020405

Caution Comments

2.056

Uses a Nimbus 2000 broomstick


2.067

--

Equipment Make Scanner Maker

Equipment Model 9000

Equipment Serial # 00001

Arrest Tracking #

2.701

8800000002

Arrest Agency ORI

2.702

MS0000000

Driver's License

2.703

--

Driver's License State MS

Driver's License # 111-333-666


Value

Arrest Type

2.704

Adult

Arrest Charge Set (0)

2.705

--

Citation (0) 49-7-31(1)(vi)

Charge Description (0) Hunting without an orange vest

Supplement (0) Conspiracy

Severity (0) Misdemeanor

# Counts (0) 2

Date of Offense (0) 20020401

Action (0) Arrest Charge

Charge Remarks (0) Remark for Charge 1

Type 4 Records: 14 records with IDC values from 1 to 14

Record Header (len) 19

Information Designation Character (idc) 1 through 14

Impression Type (imp) 1 for finger positions 1-10; 0 for finger positions 11-14

Finger Position (fgp) 1 through 14 in the first position followed by 5 bytes of -1

Image Scanning Resolution (isr) 1

Horizontal Line Length (hll) 700 for finger positions 1-10 and 13-14; 500 for finger positions 11-12

Vertical Line Length (vll) 700

Compression Algorithm (gca) 1

Image Data (data) <a one byte image with a value of 0>


G.1.2 ARR Non-Binary Field Format

Type 1 record:

1.01:194<GS>

1.02:0502<GS>

1.03:1<US>15<RS>2<US>0<RS>4<US>1<RS>4<US>2<RS>4<US>3<RS>4<US>4<RS>

4<US>5<RS>4<US>6<RS>4<US>7<RS>4<US>8<RS>4<US>9<RS>4<US>10<RS>

4<US>11<RS>4<US>12<RS>4<US>13<RS>4<US>14<GS>

1.04:ARR<GS>

1.05:20020405<GS>

1.07:MS0000000<GS>

1.08:MS0000000<GS>

1.09:ls000000-20150315-0025<GS>

1.11:19.69<GS>

1.12:19.69<FS>

Type 2 record:

2.001:680<GS>

2.002:0<GS>

2.009:02-123456<GS>

2.016:123456789<RS>987654321<GS>

2.017:Natl Agency Nr<US>12-X45<GS>

2.018:POTTER<US>HAROLD<US>ALBERT<US>JR<GS>

2.020:YY<GS>

2.021:EN<GS>

2.022:19800831<GS>

2.024:Male<GS>

2.025:White<GS>

2.026:SC FHD<US>LIGHTNING BOLT<RS>TAT UL ARM<US>Owl<GS>

2.027:507<GS>

2.029:130<GS>

2.031:Hazel<GS>

2.032:Brown<GS>

2.035:Yes<GS>

2.036:No<GS>

2.038:20020405<GS>

2.039:Construction<RS>Reynolds Corp.<RS><RS>Suite 45<RS>Rivervill

e, MS 22222<GS>

2.041:200 Side Street<RS>Apt. 40<RS>Riverville, MS 22225<GS>

2.045:20020405<GS>

2.056:Uses a Nimbus 2000 broomstick<GS>

2.067:LiveScan Maker<RS>9000<RS>00001<GS>

2.701:8800000002<GS>

2.702:MS0000000<GS>

2.703:MS<US>111-333-666<GS>

2.704:Adult<GS>

2.705:49-7-31(1)(vi)<US>Hunting without an orange vest<US>Conspir

e<US>Misdemeanor<US>2<US>20020401<US>Arrest Charge<US>Remar

k for charge 1<FS>


G.1.3 ARR MIME Email Message Format

From [email protected] Tue Apr 15 11:27:01 2003

... ...

Date: Tue, 15 Apr 2003 11:27:01 -0400 (EDT)


... ...

From: Livescan <[email protected]>


Subject: ARR; 8800000002; POTTER, HAROLD; 19800831; L

... ...

Mime-Version: 1.0

Content-Type: application/octet-stream

Content-Transfer-Encoding: base64

MS4wMToxOTQdMS4wMjowNTAyHTEuMDM6MR8xNR4yHzAeNB8xHjQfMh40HzMeNB80HjQfNR40HzYe

NB83HjQfOB40HzkeNB8xMB40HzExHjQfMTIeNB8xMx40HzE0HTEuMDQ6QVJSHTEuMDU6MjAwMjA0

MDUdMS4wNzpNUzAwMDAwMDAdMS4wODpNUzAwMDAwMDAdMS4wOTpDRVJULWxzMDAwMDAwLUFSUi0x

HTEuMTE6MTkuNjkdMS4xMjoxOS42ORwyLjAwMTo2ODAdMi4wMDI6MB0yLjAwOTowMi0xMjM0NTYd

Mi4wMTY6MTIzNDU2Nzg5Hjk4NzY1NDMyMR0yLjAxNzpOYXRsIEFnZW5jeSBOch8xMi1YNDUdMi4w

MTg6UE9UVEVSH0hBUk9MRB9BTEJFUlQfSlIdMi4wMjA6WVkdMi4wMjE6RU4dMi4wMjI6MTk4MDA4

MzEdMi4wMjQ6TWFsZR0yLjAyNTpXaGl0ZR0yLjAyNjpTQyBGSEQfTElHSFROSU5HIEJPTFQeVEFU

IFVMIEFSTR9Pd2wdMi4wMjc6NTA3HTIuMDI5OjEzMB0yLjAzMTpIYXplbB0yLjAzMjpCcm93bh0y

LjAzNTpZZXMdMi4wMzY6Tm8dMi4wMzg6MjAwMjA0MDUdMi4wMzk6Q29uc3RydWN0aW9uHlJleW5v

bGRzIENvcnAuHh5TdWl0ZSA0NR5SaXZlcnZpbGxlLCBNUyAyMjIyMh0yLjA0MToyMDAgU2lkZSBT

dHJlZXQeQXB0LiA0MB5SaXZlcnZpbGxlLCBNUyAyMjIyNR0yLjA0NToyMDAyMDQwNR0yLjA1NjpV

c2VzIGEgTmltYnVzIDIwMDAgYnJvb21zdGljax0yLjA2NzpMaXZlU2NhbiBNYWtlch45MDAwHjAw

MDAxHTIuNzAxOjgwMDAwMDAwMDIdMi43MDI6TVMwMDAwMDAwHTIuNzAzOk1THzExMS0zMzMtNjY2

HTIuNzA0OkFkdWx0HTIuNzA1OjQ5LTctMzEoMSkodmkpH0h1bnRpbmcgd2l0aG91dCBhbiBvcmFu

Z2UgdmVzdB9Db25zcGlyYWN5H01pc2RlbWVhbm9yHzIfMjAwMjA0MDEfQXJyZXN0IENoYXJnZR9S

ZW1hcmsgZm9yIGNoYXJnZSAxHAAAABMBAQE/Pz8/PwECPwI/AQAAAAATAgECPz8/Pz8BAj8CPwEA

AAAAEwMBAz8/Pz8/AQI/Aj8BAAAAABMEAQQ/Pz8/PwECPwI/AQAAAAATBQEFPz8/Pz8BAj8CPwEA

AAAAEwYBBj8/Pz8/AQI/Aj8BAAAAABMHAQc/Pz8/PwECPwI/AQAAAAATCAEIPz8/Pz8BAj8CPwEA

AAAAEwkBCT8/Pz8/AQI/Aj8BAAAAABMKAQo/Pz8/PwECPwI/AQAAAAATCwALPz8/Pz8BAT8DPwEA

AAAAEwwADD8/Pz8/AQE/Az8BAAAAABMNAA0/Pz8/PwEGQAM/AQAAAAATDgAOPz8/Pz8BBkADPwEA


G.2 Applicant Transaction

A sample of an APP transaction is shown in this appendix. Appendix G.2.1 lists the contents of the Type 1, Type 2, and Type 4 records of the transaction. The transaction includes 14 Type 4 records, each with an image field, which for sample purposes only, consists of a single zero byte.


Appendix G.2.3 shows a complete email message containing the transaction from Appendix G.2.1. The transaction is very short because of the small size of the Type 4 test records. Ordinarily, a transaction with 14 finger print images is more than 650,000 bytes in size before Base64 encoding and 860,000 bytes after encoding.



G.2.1 APP Transaction Field Contents

Value

Type 1 Record:

Record Header

1.01 (len)

194 (Calculated)

Version Number

1.02 (ver)

0502

File Contents

1.03 (cnt)

--


1


15























Value










Type of Transaction

1.04 (tot)

APP

Transaction Date

1.05 (dat)

20020405

Print Agency ORI

1.07 (dai)

MS0000000


1.08 (ori)

MS0000000

Transaction Control Number

1.09 (tcn)

ls000000-20150315-6775


1.11 (nsr)

19.69


1.12 (ntr)

19.69

Type 2 Record:

Record Header

2.001 (len)

527 (Calculated)


2.002 (icd)

0


2.009

02-123456

Social Security #

2.016

123456789

Miscellaneous Id #

2.017

--



Misc Id # Type (1) Passport Nr

Misc Id # Value (1) 1234567000

Name

2.018

--

Last Name (0) POTTER

First Name (0) HAROLD

Middle Name (0) JAMES

Name Suffix (0)

Last Name (1) HARRY

First Name (1) X

Middle Name (1)

Name Suffix (1)

Place of Birth

2.020

YY


Value


2.021

EN

Date of Birth

2.022

19800831

Sex/Gender

2.024

Male

Race

2.025

White

Scars, Marks, and Tattoos

2.026

--

SMT Code (0) SC FHD

SMT Description (0) LIGHTNING BOLT

Height

2.027

507

Weight

2.029

130

Eye Color

2.031

Green

Hair Color

2.032

Black

Reason Fingerprinted

2.037

Law Enforcement

Date Printed

2.038

20020405

Employment

2.039

--

Occupation Wizard

Employer Name Wizards Ltd

Employer Address 1 234 River St.

Employer Address 2 Suite 45

Employer Address 3 Riverville, MS 22222

Residence

2.041

--

Residence Address 1 200 Side Street

Residence Address 2 (no data)

Residence Address 3 Riverville, MS 22225


2.067

--




Driver's License

2.703

--



Response Address

2.707

--

Response Addressee Severus Snape

Response Address 1 (no data)

Response Address 2 (no data)

Response Address 3 Hogwarts Castle, Wales


Value

Response Phone # 222-111-4444












G.2.2 APP Non-Binary Field Format

Type 1 record:

1.01:194<GS>

1.02:0502<GS>




1.04:APP<GS>

1.05:20020405<GS>

1.07:MS0000000<GS>

1.08:MS0000000<GS>

1.09:ls000000-20150315-6775<GS>

1.11:19.69<GS>

1.12:19.69<FS>

Type 2 record:

2.001:527<GS>

2.002:0<GS>

2.009:02-123456<GS>

2.016:123456789<GS>

2.017:Natl Agency Nr<US>12-X45<RS>Passport Nr<US>1234567000<GS>

2.018:POTTER<US>HAROLD<US>JAMES<US><RS>HARRY<US>X<US><US><GS>

2.020:YY<GS>

2.021:EN<GS>

2.022:19800831<GS>

2.024:Male<GS>

2.025:White<GS>

2.026:SC FHD<US>LIGHTNING BOLT<GS>

2.027:507<GS>

2.029:130<GS>

2.031:Green<GS>

2.032:Black<GS>

2.037:Law Enforcement<GS>

2.038:20020405<GS>

2.039:Wizard<RS>Wizards Ltd<RS>234 River St.<RS>Suite 45<RS>River

ville, MS 22222<GS>

2.041:200 Side Street<RS><RS>Riverville, MS 22225<GS>


2.703:MS<US>111-333-666<GS>

2.707:Severus Snape<RS><RS><RS>Hogwarts Castle, Wales<RS>222-111-

4444<FS>


G.2.3 APP Email Message MIME Format


... ...

Date: Tue, 15 Apr 2003 11:27:00 -0400 (EDT)


... ...



Subject: APP; MS0000000; POTTER, HAROLD; 19800831; L

... ...

Mime-Version: 1.0




NB83HjQfOB40HzkeNB8xMB40HzExHjQfMTIeNB8xMx40HzE0HTEuMDQ6QVBQHTEuMDU6MjAwMjA0

MDUdMS4wNzpNUzAwMDAwMDAdMS4wODpNUzAwMDAwMDAdMS4wOTpDRVJULWxzMDAwMDAwLUFQUC0x

HTEuMTE6MTkuNjkdMS4xMjoxOS42ORwyLjAwMTo1MjcdMi4wMDI6MB0yLjAwOTowMi0xMjM0NTYd

Mi4wMTY6MTIzNDU2Nzg5HTIuMDE3Ok5hdGwgQWdlbmN5IE5yHzEyLVg0NR5QYXNzcG9ydCBOch8x

MjM0NTY3MDAwHTIuMDE4OlBPVFRFUh9IQVJPTEQfSkFNRVMfHkhBUlJZH1gfHx0yLjAyMDpZWR0y

LjAyMTpFTh0yLjAyMjoxOTgwMDgzMR0yLjAyNDpNYWxlHTIuMDI1OldoaXRlHTIuMDI2OlNDIEZI

RB9MSUdIVE5JTkcgQk9MVB0yLjAyNzo1MDcdMi4wMjk6MTMwHTIuMDMxOkdyZWVuHTIuMDMyOkJs

YWNrHTIuMDM3OkxhdyBFbmZvcmNlbWVudB0yLjAzODoyMDAyMDQwNR0yLjAzOTpXaXphcmQeV2l6

YXJkcyBMdGQeMjM0IFJpdmVyIFN0Lh5TdWl0ZSA0NR5SaXZlcnZpbGxlLCBNUyAyMjIyMh0yLjA0

MToyMDAgU2lkZSBTdHJlZXQeHlJpdmVydmlsbGUsIE1TIDIyMjI1HTIuMDY3OkxpdmVTY2FuIE1h

a2VyHjkwMDAeMDAwMDEdMi43MDM6TVMfMTExLTMzMy02NjYdMi43MDc6U2V2ZXJ1cyBTbmFwZR4e

HkhvZ3dhcnRzIENhc3RsZSwgV2FsZXMeMjIyLTExMS00NDQ0HAAAABMBAQE/Pz8/PwECPwI/AQAA

AAATAgECPz8/Pz8BAj8CPwEAAAAAEwMBAz8/Pz8/AQI/Aj8BAAAAABMEAQQ/Pz8/PwECPwI/AQAA

AAATBQEFPz8/Pz8BAj8CPwEAAAAAEwYBBj8/Pz8/AQI/Aj8BAAAAABMHAQc/Pz8/PwECPwI/AQAA

AAATCAEIPz8/Pz8BAj8CPwEAAAAAEwkBCT8/Pz8/AQI/Aj8BAAAAABMKAQo/Pz8/PwECPwI/AQAA

AAATCwALPz8/Pz8BAT8DPwEAAAAAEwwADD8/Pz8/AQE/Az8BAAAAABMNAA0/Pz8/PwEGQAM/AQAA

AAATDgAOPz8/Pz8BBkADPwEA


G.3 DOC Inmate Receipt Transaction

A sample of a DOC transaction is shown in this appendix. Appendix G.3.1 lists the contents of the Type 1, Type 2, and Type 4 records of the transaction. The transaction includes 14 Type 4 records, each with an image field, which for sample purposes only, consists of a single zero byte.


Appendix G.3.3 shows a complete email message containing the transaction from Appendix G.3.1. The transaction is very short because of the small size of the Type 4 test records. Ordinarily, a transaction with 14 finger print images is more than 650,000 bytes in size before Base64 encoding and 860,000 bytes after encoding



G.3.1 DOC Transaction Field Contents

Value

Type 1 Record:

Record Header

1.01 (len)

194 (Calculated)

Version Number

1.02 (ver)

0502

File Contents

1.03 (cnt)

--


1


15























Value










Type of Transaction

1.04 (tot)

DOC

Transaction Date

1.05 (dat)

20020405

Print Agency ORI

1.07 (dai)

MS0000000


1.08 (ori)

MS0000000

Transaction Control No

1.09 (tcn)

ls000000-20150315-9999


1.11 (nsr)

19.69


1.12 (ntr)

19.69

Type 2 Record:

Record Header

2.001 (len)

367 (Calculated)


2.002 (idc)

1


2.009

02-123456

Social Security #

2.016

123456789

Miscellaneous Id #

2.017

--



Misc Id # Type (1) Passport Nr

Misc Id # Value (1) 1234567-007

Name

2.018

--

Last Name (0) BOND

First Name (0) JAMES

Middle Name (0) ALBERT

Name Suffix (0)

Place of Birth

2.020

YY


2.021

EN

Date of Birth

2.022

19550315

19520513


Value

Sex/Gender

2.024

Male

Race

2.025

White

Height

2.027

601

Weight

2.029

180

Eye Color

2.031

Blue

Hair Color

2.032

Brown

Palm Prints Available

2.035

No

Photo Available

2.036

Yes

Date Printed

2.038

20020405

Caution Comments

2.056

Carries a Walther PPK


2.067

--




Driver's License

2.703

--



DOC Number

2.709

DOC222222












G.3.2 DOC Non-Binary Field Format

Type 1 record:

1.01:194<GS>

1.02:0502<GS>




1.04:DOC<GS>

1.05:20020405<GS>

1.07:MS0000000<GS>

1.08:MS0000000<GS>

1.09:ls000000-20150315-9999<GS>

1.11:19.69<GS>

1.12:19.69<FS>

Type 2 record:

2.001:367<GS>

2.002:0<GS>

2.009:02-123456<GS>

2.016:123456789<GS>

2.017:Natl Agency Nr<US>12-X45<RS>Passport Nr<US>1234567-007<GS>

2.018:BOND<US>JAMES<US>ALBERT<US><GS>

2.020:YY<GS>

2.021:EN<GS>

2.022:19550315<RS>19520513<GS>

2.024:Male<GS>

2.025:White<GS>

2.027:601<GS>

2.029:180<GS>

2.031:Blue<GS>

2.032:Brown<GS>

2.035:No<GS>

2.036:Yes<GS>

2.038:20020405<GS>

2.056:Carries a Walther PPK<GS>


2.703:MS<US>111-333-666<GS>

2.709:DOC222222<FS>


G.3.3 DOC MIME Email Message Format


... ...

Date: Tue, 15 Apr 2003 11:27:01 -0400 (EDT)


... ...



Subject: DOC; DOC222222; BOND, JAMES; 19550315; L

... ...

Mime-Version: 1.0




NB83HjQfOB40HzkeNB8xMB40HzExHjQfMTIeNB8xMx40HzE0HTEuMDQ6RE9DHTEuMDU6MjAwMjA0

MDUdMS4wNzpNUzAwMDAwMDAdMS4wODpNUzAwMDAwMDAdMS4wOTpDRVJULWxzMDAwMDAwLURPQy0x

HTEuMTE6MTkuNjkdMS4xMjoxOS42ORwyLjAwMTozNjcdMi4wMDI6MB0yLjAwOTowMi0xMjM0NTYd

Mi4wMTY6MTIzNDU2Nzg4HTIuMDE3Ok5hdGwgQWdlbmN5IE5yHzEyLVg0NR5QYXNzcG9ydCBOch8x

MjM0NTY3LTAwNx0yLjAxODpCT05EH0pBTUVTH0FMQkVSVB8dMi4wMjA6WVkdMi4wMjE6RU4dMi4w

MjI6MTk1NTAzMTUeMTk1MjAzMTMdMi4wMjQ6TWFsZR0yLjAyNTpXaGl0ZR0yLjAyNzo2MDEdMi4w

Mjk6MTgwHTIuMDMxOkJsdWUdMi4wMzI6QnJvd24dMi4wMzU6Tm8dMi4wMzY6WWVzHTIuMDM4OjIw

MDIwNDA1HTIuMDU2OkNhcnJpZXMgYSBXYWx0aGVyIFBQSx0yLjA2NzpMaXZlU2NhbiBNYWtlch45

MDAwHjAwMDAxHTIuNzAzOk1THzExMS0zMzMtNjY2HTIuNzA5OkRPQy0yMjIyMjIcAAAAEwEBAT8/

Pz8/AQI/Aj8BAAAAABMCAQI/Pz8/PwECPwI/AQAAAAATAwEDPz8/Pz8BAj8CPwEAAAAAEwQBBD8/

Pz8/AQI/Aj8BAAAAABMFAQU/Pz8/PwECPwI/AQAAAAATBgEGPz8/Pz8BAj8CPwEAAAAAEwcBBz8/

Pz8/AQI/Aj8BAAAAABMIAQg/Pz8/PwECPwI/AQAAAAATCQEJPz8/Pz8BAj8CPwEAAAAAEwoBCj8/

Pz8/AQI/Aj8BAAAAABMLAAs/Pz8/PwEBPwM/AQAAAAATDAAMPz8/Pz8BAT8DPwEAAAAAEw0ADT8/

Pz8/AQZAAz8BAAAAABMOAA4/Pz8/PwEGQAM/AQAxMC4wMDE6MTU3HTEwLjAwMzpGQUNFHTEwLjAw

NDpNU0NFUlQ0HTEwLjAwNToyMDAyMDQwNR0xMC4wMDY6MR0xMC4wMDc6MR0xMC4wMDg6MB0xMC4w

MDk6MR0xMC4wMTA6MR0xMC4wMTE6SlBFR0IdMTAuMDEyOllDQx0xMC4wMjA6Rh0xMC4wMjI6R0xB

U1NFUx4dMTAuOTk5Olgc


APPENDIX H SAMPLE TYPE 10 AND TYPE 15 RECORDS

This appendix contains examples of Type 10 and Type 15 records. The purpose of the appendix is as an aid to a scanning station vendor in determining whether the records are being properly formatted in accordance with Appendices A and B.


H.1 Type 10 Facial and SMT Image Records (future)

A sample of a Type 10 Facial Record and a Type 10 SMT record is shown in this appendix. Appendix H.1.1 lists the contents of the Type 10 records. Appendix H.1.2 shows the non-binary fields of the records defined in H.1.1 in NIST-2011 format, including the record separators.



H.1.1 Type 10 Record Field Contents

Facial Record:

Value

Record Header

10.001 (len)

242426 (Calculated)


10.002 (idc)

16

Image Type

10.003 (imt)

FACE

Source Agency ORI

10.004 (src)

MS00000000

Photo Capture Date

10.005 (phd)

20110414


10.006 (hll)

480


10.007 (vll)

600

Scale Units

10.008 (slc)

1


10.009 (thps)

1


10.010 (tvps)

1


10.011 (cga)

JPEGB

Color Space

10.012 (csp)

SRGB

Subject Acquisition Profile

10.013 (sap)

30


10.016 (shps)

1


10.017 (svps)

1

Distortion

10.018 (dist)

--

Distortion Code (idk) Barrel

Distortion Measurement Code (idm) E

Distortion Severity Code (dsc) Moderate

Lighting Artifacts

10.019 (laf)

H

Subject Pose

10.020 (pos)

D


Value

Photo Acquisition Source

10.023 (pas)

<not included if SAP is < 40>

Photo Attribute Code (pac) <not included if SAP is < 40>

Vendor-Specific Description (vsd) <not included if SAP is < 40>

Subject Quality Scores

10.024 (sqs)

--

Quality Score (qvu) 101

Algorithm Vendor Identification (qav) AAAA

Algorithm Product Identification (qap) 500

Subject Pose Angles

10.025 (spa)

--

Yaw Angle (yaw) +100

Pitch Angle (pit) +45

Roll Angle (rol) -20

Uncertainty in Degrees for a Yaw (yawu) 0

Uncertainty in Degrees for a Pitch (pitu) 3

Uncertainty in Degrees for a Roll (rolu) 20

Subject Facial Description

10.026 (sxs)

BEARD

Subject Eye Color

10.027 (sec)

BRO

Subject Hair Color

10.028 (shc)

BLK

2D Facial Feature Points

10.029 (ffp)

--

Feature Point Type (fpt) 1

Feature Point Code (fpc) 1.4

X Coordinate (hcx) 21

Y Coordinate (hcy) 235


10.030 (dmm)

CONTROLLED

Feature Contours

10.033 (fec)

--

Feature Contour Code (fcc) eyetop

Number of Points (nop) 25

Horizontal Point Offset (hpo) 420

Vertical Point Offset (vpo) 599

Comment

10.038 (com)

None of this sample data makes sense.


10.039 (T10)

2

Image Transform

10.044 (itx)

CROP

Occlusions

10.045 (occ)

--

Occlusion Opacity (ocy) T

Occlusion Type (oct) R

Number of Points (nop) 52

Horizontal Point Offset (0) (hpo) 420

Vertial Point Offset (0) (vpo) 599

Horizontal Point Offset (1) (hpo) 100


Value

Vertial Point Offset (1) (vpo) 153


10.902 (ann)

--

Greenwich Mean Time (gmt) 20120126112233Z

Processing Algorithm Name Version (nav) Smith’s Algorithm

Algorithm Owner (own) Mr. Smith

Process Description (pro) A secret.


10.903 (dui)

P


10.904 (mms)

--

Make (mak) Smith’s

Model (mod) S-001

Serial Number (ser) 1234D347

Source Agency Name

10.993 (san)

Smithville

Hash

10.996 (has)

<calculated>


10.998 (geo)

--

Universal Time Entry (ute) <null>

Latitude Degree Value (ltd) 25.85

Latitude Minute Value (ltm) <null>

Latitude Second Value (lts) <null>

Longitude Degree Value (lgd) 85.112

Longitude Minute Value (lgm) <null>

Longitude Second Value (lgs) <null>

Elevation (ele) <null>

Geodetic Datum Code (gdc) BES

Geographic Coordinate Universal Traverse Mercator Zone (gcm)

3F

Geographic Coordinate Universal Traverse Mercator Easting (gce)

23

Geographic Coordinate Universal Traverse Mercator Northing (gcn)

224

Geographic Reference Text (grt) <null>

Geographic Coordinate Other System Identifier (osi)

GARS

Geographic Coordinate Other System Value (ocv)

<null>

Body Part Image

10.999 (data)

<image data>


SMT Record:

Value

Record Header

10.001 (len)

25971 (Calculated)


10.002 (idc)

17

Image Type

10.003 (imt)

TATTOO

Source Agency ORI

10.004 (src)

MS00000000

Photo Capture Date

10.005 (phd)

20110414


10.006 (hll)

350


10.007 (vll)

480

Scale Units

10.008 (slc)

1


10.009 (thps)

1


10.010 (tvps)

1


10.011 (cga)

JPEGB

Color Space

10.012 (csp)

SRGB


10.016 (shps)

1


10.017 (svps)

1


10.030 (dmm)

CONTROLLED


10.039 (T10)

1

NCIC SMT Code

10.040 (smt)

TAT BACK

SMT Size

10.041 (sms)

--

Height (hgt) 36

Width (wid) 29

SMT Descriptors

10.042 (smd)

--

SMT Code Indicator (smi) (0) TATTOO

Tattoo Class (tac) (0) ANIMAL

Tattoo Subclass (tsc) (0) DRAGON

Tattoo Description (tds) (0) <null>

SMT Code Indicator (smi) (1) BRANDED

Tattoo Class (tac) (1) PLANT

Tattoo Subclass (tac) (1) ROSE

Tattoo Description (tds) (1) with thorns

Tattoo Color

10.043 (col)

--

Predominant Color (tc1) (0) BLACK


Additional Color (tc2) (0) RED

Predominant Color (tc1) (1) RED

Additional Color (tc2) (1) <null>

Image Transform

10.044

DOWNSAMPLE


10.902 (ann)

<null>

Greenwich Mean Time (gmt) --

Processing Algorithm Name Version (nav) --

Algorithm Owner (own) --

Process Description (pro) --


10.903 (dui)

<null>


10.904 (mms)

--

Make (mak) AAA

Model (mod) A-2999

Serial Number (ser) A-2999 45738

Source Agency Name

10.993 (san)

Smallville PD

Hash

10.996 (has)

<calculated>


10.998 (geo)

--

Universal Time Entry (ute) <null>

Latitude Degree Value (ltd) -85

Latitude Minute Value (ltm) 21.3


Longitude Degree Value (lgd) 30.5

Longitude Minute Value (lgm) <null>

Longitude Second Value (lgs) <null>

Elevation (ele) -422

Geodetic Datum Code (gdc) <null>


<null>


<null>


<null>

Geographic Reference Text (grt) <null>


LANDMARK


More detailed information.

Body Part Image

10.999 (data)

<image data>


H.1.2 Type 10 Record Non-Binary Field Format

Type 10 Facial Record:

10.001:242426<GS>

10.002:16<GS>

10.003:FACE<GS>

10.004:MS00000000<GS>

10.005:20110414<GS>

10.006:480<GS>

10.007:600<GS>

10.008:0<GS>

10.009:1<GS>

10.010:1<GS>

10.011:JPEGB<GS>

10.012:SRGB<GS>

10.013:20<GS>

10.016:1<GS>

10.017:1<GS>

10.020:D<GS>

10.024:101<US>AAAA<US>500<GS>

10.025:+100<US>+45<US>-30<US>0<US>3<US>20<GS>

10.026:BEARD<GS>

10.027:BROWN<GS>

10.029:1<US>1.4<US>21<US>235<gs>

10.030:CONTROLLED<GS>

10.999:<image data>

Type 10 SMT Record:

10.001:25971<GS>

10.002:17<GS>

10.003:TATTOO<GS>

10.004:MS00000000<GS>

10.005:20110414<GS>

10.006:350<GS>

10.007:480<GS>

10.008:0<GS>

10.009:1<GS>

10.010:1<GS>

10.011:JPEGB<GS>

10.012:SRGB<GS>

10.016:1<GS>

10.017:1<GS>


10.040:TAT BACK<GS>

10.041:36<US>29<GS>

10.042:TATTOO<US>ANIMAL<US>DRAGON<RS>BRANDED<US>PLANT<US>ROSE<US>with thorns<GS>

10.043:BLACK<US>RED<RS>RED<GS>

10.999:<image data>


H.2 Type 15 Palm Print Image Record

A sample of a Type 15 Palm Print record is shown in this appendix. Appendix H.2.1 lists the contents of the Type 15 records. Appendix H.2.2 shows the non-binary fields of the records defined in H.2.1 in NIST-2011 format, including the record separators.



H.2.1 Type 15 Record Field Contents

Value

RecordHeader

15.001 (len)

123096 (Calculated)


15.002 (idc)

18

Impression Type

15.003 (imp)

10

Source Agency

15.004 (src)

MS00000000

Palm Print Capture Date

15.005 (pcd)

20110414

Horizontal Line length

15.006 (hll)

900


15.007 (vll)

1112

Scale Units

15.008 (slc)

1


15.009 (thps)

1


15.010 (tvps)

1


15.011 (cga)

WSQ20

Bits Per Pixel

15.012 (bpx)

8

Friction Ridge Generalized Position

15.013 (fgp)

21


15.016 (shps)

1


15.017 (svps)

1


15.018 (amp)

--

Friction Ridge Amputated or Bandaged Position (frap)

21

Amputated or Bandaged Code (abc) XX

Comment

15.020 (com)

Right Palm Comment

Palm Print Quality Metric

15.024 (pqm)

--

Friction Ridge Metric Position (frmp) 21

Quality Value (qvu) 150


Value

Algorithm Vendor Identification (qav) B1B1

Algorithm Product Identification (qap) 237


15.030 (dmm)

CONTROLLED


15.902 (ann)

--

Greenwich Mean Time (gmt) 20111224134002Z

Processing Algorithm Name Version (nav) Algorithm XYZ

Algorithm Owner (own) ABC Corp.

Process Description (pro) A description of the algorithm


15.903 (dui)

P123456789012


15.904 (mms)

--

Make (mak) Acme

Model (mod) P-37

Serial Number (ser) 123-4444

Source Agency Name

10.993 (san)

Print Agency Name

Hash

15.996 (has)

<calculated>


15.998 (geo)

--

Universal Time Entry (ute) 20111224102315Z

Latitude Degree Value (ltd) 75

Latitude Minute Value (ltm) 21.4


Longitude Degree Value (lgd) 60

Longitude Minute Value (lgm) 22

Longitude Second Value (lgs) .5

Elevation (ele) -200.15

Geodetic Datum Code (gdc) AIRY


60D


20019


114236

Geographic Reference Text (grt) Hollywood and Vine


USNG


A value from the Other System

Palm Print Image

15.999 (data)

<image data>


H.2.2 Type 15 Record Non-Binary Field Format

Type 15 Record:

15.001:123096<GS>

15.002:18<GS>

15.003:10<GS>

15.004:MS00000000<GS>

15.005:20110414<GS>

15.006:900<GS>

15.007:1112<GS>

15.008:0<GS>

15.009:1<GS>

15.010:1<GS>

15.011:WSQ20<GS>

15.012:8<GS>

15.013:21<GS>

15.016:1<GS>

15.017:1<GS>

15.020:Right Palm Comment<GS>

15.024:20<US>150<US>B1B1<US>237<GS>


15.999:<image data>


APPENDIX I CARD SAMPLES


I.1 Mississippi State Arrest Card



I.2 FBI Applicant Card


I.3 FBI Palm Print Card FD-884


Documents

MCHS Tenprint Interface Control Document (ICD)