Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

NOTE: The following comments are related to each other (asking to break the one-to-one correspondence with Part 1, making mandatory fielDHS-OCIO numbers 1; 3; 7;10-12; 14-15; 17-18; 21; and possibly 4-6,9,19, and 20 as well as TSC numbers 2-15 and 17-18. Daon-5 ge The standard states that order is mandatory, yet 

the order of the elements presented in the tables that describe the record layouts is confusing. The elements are not ordered by associated Part 1 field numbers, which would seem to be the most logical sequence (with some understandable exceptions for the XML translation). This is especially confusing for the Type-10 record in Table 218, where the User Defined Fields (corresponding to field numbers 10.200-10.998) appear before other specified fields in this XML standard, but they are some of the last elements in Part 1. 

Provide an explanation to the ordering (Section 207.1 may be a logical section for this), or reorder the elements in the tables to better align to the Part 1 standard. 

DHS- Forewor Lines 3-9 te The following passage is very useful in helping to If this comment is acceptable, please let 

OCIO- d on page understand that the scope of the standard. This us (DHS) know and we’ll gladly help to 

01 vii scope has probably held true for the life of the 

standard to-date; perhaps we could expand the purpose of the standard to support scenarios that 

include combating-terrorism in war zones, counter-terrorism intelligence, homeland security border protection, person encounters, and BOLOrelated alerts, warnings and notifications. “ Various levels of law enforcement and related criminal justice agencies as well as identity management organizations procure equipment and systems intended to facilitate the determination of the personal identity of a 

redraft the text for this section to discuss the growing number of use cases for exchanging biometric data that 

extend beyond the current set of use cases aimed primarily at biometric enrolment systems. 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

subject from fingerprint, palm, facial (mugshot), or other biometric information (including iris data). To effectively exchange identification data across jurisdictional lines or between dissimilar systems made by different manufacturers, a standard is needed to specify a common format for the data exchange. To this end, this standard has been developed.” 

DHS- Forewor Lines 9- te The passage below is a really good way to If this comment is acceptable, please let 

OCIO- d 12 on introduce the reasoning behind an XML us (DHS) know and we’ll gladly help to 

02 page ix implementation of the standard. Moving to XML is 

a significant change for many organizations as it requires an update not only to basic software code, but usually it means adopting a whole new framework and paradigm for information sharing. The text in this passage should be expanded to begin introducing the idea that moving to XML is more than just changing from one physical file format to another; The change from Part 1 to Part 2 is also to embrace modern messaging architectures that follow the patterns of serviceoriented architectures. “Over the past several years, many data interchange and processing applications have converted to or are in the process of migrating toward an XML format approach for processing data. In order to provide the ability to directly interface with such applications, this XML alternative representation of the textual, image, and other biometric information has been 

redraft the text for this section to discuss that migration to XML not only a migration to a new file format but also likely a migration to a new architecture. 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

developed.” 

DHS- Forewor Lines 13- te The passage below clearly states the desired The GS1 (formerly EAN.UCC) community 

OCIO- d 15 on relationship between the Part 1 and the Part 2 of is a great example of a standards 

03 page ix the specification as one where Part 1 is the 

parent-document and Part 2 is a secondary version of the Part 1. The paradigm created here is that the Part 1 identifies certain logical requirements and the Part 2 is simply the XMLization of that exact same set of requirements. This approach is probably the cleanest approach in terms of honouring consistency between the different parts of the standard, but there should be a case made that XML-zing Part 1 in-and-ofitself does not deliver significant value to the existing or future user base. The value of Part 2 is also enabling the future user base to move towards a modern messaging framework that is not entangled with the legacy design of Part 1. The Part 2 is an opportunity to embrace up-todate architectures for messaging. The Part 2 enhancement of the standard should be likened to the move between EDI and XML by user communities from consumer goods, retail and manufacturing such as GS1. While they reuse the data-layer definitions from legacy EDI systems, the move to XML has been a move to a multilayered messaging architecture that capitalizes on systems that decouple data from the envelope/messaging, transaction and command layers of the stack. 

organization that took the opportunity when moving from EDI to XML to apply up-to-date architectural principles to the messaging standards. They did not abolish their existing EDIFACT and ANSI X12-based EDI messages and in fact still manage those, but for new messages and business processes, they have embraced a multi-layered messaging framework that fits into current SOA practices. This specification is XML-izing EDI-like messages and perpetuates practices of older messaging architectures as opposed to updating to SOA-based practices that do things like decouple transaction headers for the data payloads. For more examples of these types of practices, please see ANSI/INCITS organizations like GS1, OASIS and IBM. If the principles associated with comment are acceptable, please let us (DHS) know and we’ll gladly help to redraft the text for this section to discuss that migration to XML entails not only a migration to a new file format but also a migration to a message 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

“This Part 2 of this standard contains the XML alternative for the conventional ANSI/NIST standard. A goal of Part 2 is to describe a “oneto-one” correspondence of XML elements to the numerically tagged conventional elements described in Part 1.” 

frameworks. 

Daon-1 201 5th para. 

and following bullets, page 1 

ed The text references “This Part 1 version of the 

standard....” Since this is Part 2 of the standard, at the very least the first part of the paragraph should be updated. Moreover, this introduction section should provide some context for Part 2. 

Suggest rewording this paragraph and borrowing some text from the Foreword to introduce Part 2. One possibility: “As a result of workshops convened in 2005, the standard was updated and expanded into two parts. This document contains the Extensible Markup Language (XML) alternative version, or Part 2. For the conventional version, or Part 1. Over the past several years, many data interchange and processing applications have converted to or are in the process of migrating toward an XML format approach for processing data. In order to provide the ability to directly interface with such applications, this XML alternative representation of the textual, image, and other biometric information has been developed. A goal of Part 2of this standard is to describe a “one-to-one” correspondence of XML elements to the numerically tagged conventional elements described in Part 1. Another goal is to define an XML 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

representation that conforms to the National Information Exchange Model (NIEM). The Part 1 subelements (separated by the US and RS characters in the conventional representation) have been given XML counterparts in Part 2.” 

DHS- 202.1 Line 1-4 te The passage below covers the primary use case If this comment is acceptable, please let 

OCIO- Scope on page 2 for the current version of the standard very well; us (DHS) know and we’ll gladly help to 

04 the user base is law enforcement community use 

cases where scanners are used to capture biometrics while enrolling individuals. Perhaps we could take the opportunity to expand this standard so that it can be implemented by other mission communities that need to exchange biometric information as well. We could expand the scope to support scenarios that include combating-terrorism in war zones, counterterrorism intelligence, homeland security border protection, person encounters, and BOLO-related alerts, warnings and notifications. “This information is primarily intended for interchange among criminal justice administrations or organizations that rely on automated fingerprint and palmprint identification systems, or use facial/mugshot, SMT, iris, or other biometric data for identification purposes.” 

redraft the text for this section to discuss the growing number of use cases for exchanging biometric data that extend beyond the current set of use cases aimed primarily at biometric enrolment systems. 

DHS- 202.1 Line 1-4 te Perhaps the passage below should be clarified to If this comment is acceptable, please let 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

OCIO- Scope on page 2 parse out the idea that the affected software will us (DHS) know and we’ll gladly help to 05 be required to follow the standard only in as far 

as the interfaces are concerned. The standard will define the characteristics of the APIs or other interface specifications that are bundled into the software. In addition, the standard does have a significant impact on the underlying data model of any software that would conform to the standard. The software would need to support mandatory fields and code lists or at least have the ability to map to the appropriate required values. “This standard does not define the characteristics of the software that shall be required to format the textual information or to compress and reconstruct the associated digital fingerprint image information. Typical applications for this software might include, but are not limited to, computer systems associated with a live-scan fingerprinting system, a workstation that is connected to or is part of an Automated Fingerprint Identification System (AFIS), or an image storage and retrieval system containing fingerprints, facial/mugshot, SMT, or other biometric images.” 

redraft the text for this section to expand on the possibilities for different types of software systems that would aim to adhere to this standard. In addition, the additional text would specify the role of the standard in affecting the APIs, interfaces and the underlying data model of the software. 

DHS- 202.2 Line 12- te The passage below tightly defines the scope of If this comment is acceptable, please let 

OCIO- Conform 18 on the standard which is the exchange of biometric us (DHS) know and we’ll gladly help to 

06 ance page 2 information. The conformance rules will be 

derived from this foundational understanding that the standard is a data-centric specification that 

redraft the text for this section to discuss the growing number of use cases for exchanging biometric data that 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source 

& Comment 

Number 

(e.g. 

FBI-1) 

Section/ 

Clause/A 

nnex 

No. 

(e.g. 

1.1.1) 

Paragraph 

/ 

Figure/Ta 

ble/Note 

& Page 

No. 

(e.g. 

Typ 

e of 

com 

-

men 

t2 

Comment (justification for change) Proposed change 

 (provide proposed text to insert in 

document, if possible) 

Figure 1, 

p. 5) 

aims to exchange pure biometric data and not necessarily any other related mission data. This is one of the areas where the standard could be expanded to also support business processes that require the exchange of biometric data in standard ANSI/NIST formats, but the exchange is not data-centric (i.e. driven by the biometric data); it is instead business-process centric and defines other critical business data for which biometrics are a secondary data asset or subcomponent. E.g. Encounters, Suspicious Activities, BOLO Alerts, and Terrorist and other Person Watch Lists. Perhaps we could expand this section to cover additional scope such as the counterterrorism mission that could influence the resulting conformance rules that are defined in this section. “Information compiled and formatted in accordance with this standard can be recorded on machine-readable media or may be transmitted by data communication facilities. This information may have been gathered directly from a fingerprint scanner or camera in lieu of a fingerprint card, a latent fingerprint, facial/mugshot, or other types of photographs. Law enforcement, criminal justice agencies, and other organizations that process biometric data will use the standard to exchange fingerprint, palmprint, facial, iris, or other photographic images and related biometric identification data.” 

extend beyond the current set of use cases aimed primarily at biometric enrolment systems. By moving to other types of business exchanges where the biometric is an important data component but is not the central data component (e.g. Encounters, BOLO alerts and watchlist), we would increase the capacity of this standard to penetrate other systems that are involved in the supply-chain of biometric data; these systems are many times different from the ones discussed in this section. 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

DHS- 202.3 Line 20- te The passage below is one of the critical The suggestion here is a proposal for 

OCIO- Conform 26 on statements in the standard that defines the either (a) multiple levels of conformance 

07 ance page 2 meaning of “conformance” to this specification. 

The idea below is that the Type-1 record exchanges are the baseline capability required to achieve any level of conformance. The Type-1 transaction types, however, are limited to the legacy exchanges that pertain to the scope of biometric enrolment systems. There is a desire to extend beyond the existing transaction types/codes and support additional transactions and business processes related to encounters and other counterterrorism and homeland securityrelated scenarios. Some of these additional business-processes are not biometric-centric and instead biometric data is shared within the context of another key business data component. Perhaps this specification could either be (a) relaxed in terms of conformance rules to support some of the less-prescriptive/rigid data exchange scenarios or (b) extended to support several logical tiers of conformance, the highest of which would be the current definition of conformance; perhaps we could distinguish “transaction/exchange conformance” from “data conformance.” “Systems claiming conformance with this standard shall implement the transmitting and/or receiving of record types as defined by this standard. Systems claiming conformance are not required to implement every record type 

or (b) a less-rigid definition of conformance that would allow the standard to be used within business processes that depart from the traditional biometric enrolment system scenarios. There still needs to be a prescriptive definition of conformance for hardware device/scanner conformance which necessarily includes transaction level support. A different level of “data conformance” would be focused on data interoperability that can be verified by support of the appropriate data model components and elements, etc. This type of data conformance is readily supported in the NIEM model and can be verified using off the shelf capabilities associated with XML schemabased parsing and validation. NIEM is also developing capability for more robust conformance checking using Schematron technology. 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

specified herein. At a minimum, they must be capable of transmitting and receiving Type-1 records. However, in order for a transaction to be meaningful, there must be at least one additional type of record included. The implementer must document the record types supported in terms of transmitting and/or receiving. Those record types not implemented shall be ignored by the conforming system receiving a transaction.” 

DHS- 202.3 Line 36- te The passage below describes the method by which If this comment is acceptable, please let 

OCIO- Conform 37 on the specification may and may not be extended. us (DHS) know and we’ll gladly help to 

08 ance page 2 Perhaps this section could be expanded to 

describe the overarching extension strategy. This section of the document would be a good place to specify that there is an extension strategy, the reasons for the approach and examples of how and when extensions may happen. This will have direct implications on both producers and consumers of data who use this standard. All XML standards typically specify this kind of strategy especially because there are four ways to do extension in XML schema that are all widely recognized and used. 

redraft the text for this section to discuss the extension strategy. Also useful to this section would be the idea of whether other first-class objects are meant to be associated to the biometrics using these extension hooks or not. Other first class data objects might possibly consider using containment or the NIEM association types to define the relationships to the ANSI/NIST biometric data types. 

“Implementers may not introduce new elements except within the substitution elements described above, nor may they change the order or structure of elements defined by the standard.” 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

DHS- 202.3 Line 38- te The rule listed below has been one of the If this comment is acceptable, please let 

OCIO- Conform 39 on challenging obstacles related to using the us (DHS) know and we’ll gladly help to 

09 ance page 2 standard in the context of the watchlist 

specification and the future use of NIEM Suspicious Activity Reports and NIEM Encounters. Because there is only one point of access to the standards data structures and because the point of access is at the head of the messaging layer (as opposed to the data layer), the standard conflicts with the architectures specified by many organizations that do XML information sharing. DHS for example has decoupled the messaging layer from the data layer as is the practice of NIEM. This practice is inline with industry best practices prescribed for SOA and web services by groups like OASIS, GS1 and IBM. Perhaps this conformance rule could be relaxed or extended to make this requirement conditionally mandatory for the biometric enrolment use cases only. “The root element, <itl:NISTBiometricInformationExchangePackage>, may be included as a payload in a larger package.” 

redraft the text for this section to discuss the other useful points of entry into the data structure of this standard. The single root-element access point is useful for ensuring a one-to-one mapping with the Part 1 specification, but at the same time limits the practical use of the standard with out significant overhead and bad technical practice to make the standard work in scenarios such as Encounters and Watchlisting. Perhaps different root elements could be specified as acceptable based on the type of conformance that the software vendor or user is seeking— Messaging/Exchange Conformance vs. Data Interoperability Conformance. 

DHS- 202.3 Line 40- te The passage below is good indicators of an If this comment is acceptable, please let 

OCIO- Conform 41 on inherent rigidity in the standard where based on us (DHS) know and we’ll gladly help to 

10 ance page 2 transaction types and biometric mode types, 

certain data elements are defined as mandatory or conditionally-mandatory. These definitions provide significant value to the standard 

redraft the text for this section to discuss the need for supporting more thoroughly supporting partial, known and classified data elements in the 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source 

& Comment 

Number 

(e.g. 

FBI-1) 

Section/ 

Clause/A 

nnex 

No. 

(e.g. 

1.1.1) 

Paragraph 

/ 

Figure/Ta 

ble/Note 

& Page 

No. 

(e.g. 

Typ 

e of 

com 

-

men 

t2 

Comment (justification for change) Proposed change 

 (provide proposed text to insert in 

document, if possible) 

Figure 1, 

p. 5) 

particularly to ensure interoperable/predictable biometric hardware devices and in the cases where data is exchanged across or with a biometric enrolment centre. On the other hand, if this rule could be relaxed for other business scenarios such as those related to counter terrorism or field scenarios by which only partial information can be provided. The specification currently is able to address the some of the partial and unknown data scenarios when the associated data type is a text string, numeric or a enumerated code list that specifies a special code value for “unknown.” There are still scenarios such as for date time data types that can’t be implemented appropriately due to the rigidity of the W3C xsd:datetime data type used in the Part 2 message. Even further, when cardinality is 1-to-1 or 1-to-N on certain data elements, there are additional implementation issues when the data elements can not be shared due to information security classification constraints. Perhaps the specification could be relaxed to better address these other scenarios or a new edition of the standard could be published separate from Part 2 aimed at these newer, yet still important, information sharing use cases. “All required elements must be present in a conforming instance document even if the standard’s schema do not strictly enforce the requirement.” 

standard. 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

Daon-2 203 page 3 ed ANSI/NIST-ITL 1-2000 is referenced instead of 

ANSI/NIST-ITL 1-2007, Part 1. 

Include a reference to ANSI/NIST-ITL 1-2007, Part 1. 

Daon-3 204.25 XML, 

page 6 

ed Appears to be a word missing from the definition. Suggest rewording to “A convention for 

marking-up and tagging data for electronic transmission.” 

DHS- 205.6.1 Line 15 te Is this where a GIF image could be supported or Because JPG, PNG and GIF are widely 

OCIO- Color on page 8 other images of unknown quality? adopted image formats for the Web, and 

19 and because XML is inherently a Web 

grayscal “Table 201 Grayscale & color image compression technology, perhaps the specification e codes” should support the use of GIFs in the compres standard as well. sion algorith GIF uses the currently supported RGB ms color space as well. 

SAB-1 270 

[207?-

EMN] 

P 13 TE2 Suggest we set up “guidelines” for how the XML comment field should be constructed so the XML 

system could easily reconstruct a tag formatted record in a light outs manner. The majority of current systems are based on the tagged format data exchange. Wholesale replacement of all of the many interfaced systems at the same time with XML based systems is neither practical nor prudent. They will be transitioned one at a time, and the agency may not have any control over what the sending or receiving system is capable of receiving. Hence the ability to receive XML and translate it into a tagged format for 

Pick one of the structures that you have included, stay with the same comment structure for similar contents, placing tag id in the same place, and mnuemonic and define the comment structure so systems that receives the comment will know how to interpret it. 

<!-- =========================fieldMnemonic="IDC" == --> 19 <!-- ==========================fieldMnemonic="IDC" == --> 31 <!-- ==========================fieldMnemonic="BFT" == --> 22 

=====

====

====

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source 

& Comment 

Number 

(e.g. 

FBI-1) 

Section/ 

Clause/A 

nnex 

No. 

(e.g. 

1.1.1) 

Paragraph 

/ 

Figure/Ta 

ble/Note 

& Page 

No. 

(e.g. 

Typ 

e of 

com 

-

men 

t2 

Comment (justification for change) Proposed change 

 (provide proposed text to insert in 

document, if possible) 

Figure 1, 

p. 5) 

another system without losing data is a problem that needs to be solved without losing data integrity. Archives would be useless if the integrity of the data was lost due to translation errors. While it should be relatively easy to transition the tagged formats to this XML format with a data translation table/map, it will be very difficult to translate from the XML format back into the tagged format since the historical tag numbers are inconsistently presented in the XML comments both in structure and/or if available at all. The current rules of engagement are to accept the complete record and only use those fields that you need to use and pass the original record onto the next system. If an XML based system does not have the translation/mapping for a particular tagged field, the fields could be inadvertently dropped when the XML system needs to convert back into the tagged field format for another system. There are also some new fields that were introduced that should also have a complementary tag field to assure the original contents of the records can be reconstructed. It is a very real world statement that not all 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

systems will be able to simultaneously accept/process XML and the need to transition to and from the tagged fields is a real issue for existing multiple agency interfaces. 

DHS- 207 Line 34- te The passage below describes the tight data If this comment is acceptable, please let 

OCIO- Informat 39 on structure definitions within the standard and us (DHS) know and we’ll gladly help to 

11 ion 

exchang e package descript ion 

page 13 acknowledges the possibility of other message 

wrappers being used in conjunction with the standard. There is an issue however where the rigidity of the standard which includes a header within the root element in addition to the data payload that conflicts with the multi-layered approach of current messaging architectures. There are currently several layers of transaction and protocol headers in Web based transactions that would easily wrap the standard, however there is an issue where the header defined by one layer is just payload in another layer yet within the same layer, it is not possible to mix header content with payload content. This is the issue that arises between NIEM and ANSI/NIST specification. NIEM is purely a data layer standard and decouples itself from header and transaction content. The Type-1 record however is a logical header that gets embedded within the data content. Current architectures that have been designed to support SOA practices can not support the approach where a header is embedded so deeply in a message and in such context, the approach can be interpreted as poor 

redraft the text for this section to discuss the need for supporting more thoroughly supporting the decoupling of the message transaction layer and the data layers of the specification. 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

design practice. Perhaps the header can be decoupled from the standard and realigned with one or more industry best practice headers that can be assured to work with Enterprise Service Bus—Oracle, IBM, Tibco, etc--software out of the box. In addition, if the strict definitions of the data structures within the root node could be relaxed, then the biometric record types could be reused within other business data exchange processes that are not purely biometric centric, yet have a requirement to ensure that any biometric data that is shared is represented in a standard data format. “In many cases the package will be included as a payload with an XML formatted outer wrapper for transaction or protocol purposes. The package may also be a part of a larger, user-defined data structure. The standard strictly defines, however, the content of data within the <itl:NISTBiometricInformationExchangePackage> complex element.” 

Daon-4 207 1st para. 

starting on page 14 

te The text references “<nc:BinaryBase64>”, but 

other places in the document reference “<nc:BinaryBase64Object>”. 

Change text to “<nc:BinaryBase64Object>”. 

SAB-2 [207?-

EMN] 

Due to the XML A-Z naming convention the 

"binarybased64object" image usually falls at the very top of a record, with all images being a variable size. Having this variable length part at the front of the record will make it very difficult 

If you could put a "zzz" in the front of the name (ie "zzzbinarybase64object") this name would be pushed to the end of the record and save a whole lot of future human debugging time. While I 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

for analyst to locate the textual parts of the record/file. Since we are tied to the XML idiosyncrasies, it is truly necessary to keep the "Binarybase64object" name? 

understand the NC folks would have to slightly teak their code, but it would help the rest of us in the future countless man hours. 

DHS- 207.2 Line 32- te Perhaps the Type-1 record requirement described If this comment is acceptable, please let 

OCIO- Informat 36 on in the passage below can be relaxed as us (DHS) know and we’ll gladly help to 

12 ion 

exchang e package contents 

page 15 organizations have implemented and standardized 

around other industry best practice headers designed to work across multiple exchanges and can hence ensure consistency across their SOA implementations. The Type-1 record is well defined for the biometric-centric data exchange, but an organization will not resue the Type-1 record for their other non-biometric exchanges. There are industry best practices and standards for XML headers that are supported out-of-thebox by software vendors; some of the standards 

also have compliance testing operations such as ebMS who uses the Drummond Group to interoperability testing. “ Exchange packages are required to contain one and only one Type-1 logical record per transaction. The Type-1 logical record, <itl:PackageInformationRecord>, shall always be the first logical record within the package. Depending on the usage and the number of fingerprint, palmprint, facial/mugshot, SMT, iris, or other biometric images available for processing, one or more additional records may 

redraft the text for this section to discuss the need for supporting more thoroughly supporting the decoupling of the message transaction layer and the data layers of the specification. In this approach, transactions that require a standard definition for a fingerprint, palmprint, facial/mugshot, SMT, iris, or other biometric images can apply the ANSI/NIST specification. 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

be present in the package.” 

DHS- Table Line 15 te Perhaps some explanation is needed in this This section could add more description 

OCIO- 205 on page section to describe why these six transaction on the importance of these six listed use 

13 Number 

of logical records per transact ion 

16 types are listed in the table but none of the other 

ones from Part 1 are. If these are intended to be the 80% use case or the full scope of Part 2, perhaps that could be clarified in this section. “ Master file inquiry Latent inquiry 

cases. If this comment is acceptable, please let us (DHS) know and we’ll gladly help to redraft the text for this section. Though, in addition, DHS will need to support additional business processes. If additional business processes are beyond 

File maintenance Image request Search response Image request response” 

the scope of this specification, than the conformance rules should not apply as-is or might need to be enhanced to provide appropriate guidance or leeway in new transaction types. E.g. the sharing of biometric data in the context of and Encounter or a Terrorist Watchlist Exchange or a BOLO message. 

DHS- 208.1.1 Line 4-9 te The passage below continues to reiterate the If this comment is acceptable, please let 

OCIO- Type-1 on page prescriptive use of a header within the payload of us (DHS) know and we’ll gladly help to 

14 Transact 

ion informat ion 

18 a biometrics transaction. The Type 1 should 

continue to be prescriptively specified for such biometric enrolment use cases. However, for other scenarios where other XML headers serve as 

redraft the text for this section to discuss the need for supporting more thoroughly supporting partial, known and classified data elements in the 

record better solutions and where certain information standard. 

such as originator source information is difficult to share because it is unknown or classified for If this comment is acceptable, please let security reasons, the specification should be us (DHS) know and we’ll gladly help to specified more flexibly to address these different redraft the text for this section to 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

use cases. “ The XML name for the Type-1 record is <itl:PackageInformationRecord>, and its <ansi5 nist:RecordCategoryCode> element shall have a value of “01”. A Type-1 logical record is mandatory and is required for each exchange package. The Type-1 record shall provide information describing type and use or purpose for the transaction involved, a listing of each logical record included in the file, the originator or source of the physical record, and other useful and required information items.” 

discuss the need for supporting more thoroughly supporting the decoupling of the message transaction layer and the data layers of the specification. 

RAY-1 P. 18 

Line 19 -21 

te Would it result in format errors if using ‘3’, ‘4’, 

‘5’, and ‘6’ for logical record types instead of ‘03’, ‘04’, ‘05’, and ‘06’? 

MNT-1 208.1.3 Table 

206, page 30 

ed Maximum pixel density for transmitting Type-3 

and Type-5 records should be 262.5 ppi 

Change both occurrences of 252.50 to 262.50 in the table 

DHS- Table Line 1 on te Perhaps the standard could be relaxed for some If this comment is acceptable, please let 

OCIO- 206 page 19 scenarios where the image resolution of the us (DHS) know and we’ll gladly help to 

15 Resoluti fingerprint is unknown. redraft the text for this section. 

on of Transmi “ Table 206 Resolution of Transmitted fingerprint tted image records fingerpri Preferred nt Pixel Density image Maximum records Pixel Density” 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

DHS- 208.1.4 Line 3 on te Is this where a GIF image could be supported or Because JPG, PNG and GIF are widely 

OCIO- Type-7 page 20 other images of unknown quality? adopted image formats for the Web, and 

16 Userdefined because XML is inherently a Web technology, perhaps the specification 

image record 

should support the use of GIFs in the standard as well. 

DHS- 209 Line 30 te The passage below continues to reiterate the It is recommended that the standard 

OCIO- Type-1 on page prescriptive use of a header within the payload of recognize the value of reusing industry 

17 transact 

ion informat 

24 a biometrics transaction. The Type 1 should 

continue to be prescriptively specified for such biometric enrolment use cases. However there 

standard transaction header formats such as SOAP or ebMS. Software vendors such as IBM, Oracle, BEA, TIBCO, etc. 

ion record 

are other scenarios where other industry XML headers serve as better solutions. “209.1 XML elements for the Type-1 transaction information record” 

support these transaction headers formats out of the box. Since the inception of XML in 1998, message exchange has advanced to the point where XML standards decouple the data payload from the transaction header. If the goal is to map between the Part 1 and Part 2, a standard reference XSLT could be provided that allows organizations/agencies to use and reuse their header formats adopted by their enterprise and to define addition transaction types beyond the six presented in this standard. This would allow organizations to more easily integrate the ANSI/NIST standard into their architecture without having to 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

place dummy values into the large Type 1 header block of standard as a logically redundant section of the message. 

DHS- Table Line 2 on te The passage below continues to reiterate the If this comment is acceptable, please let 

OCIO- 207 page 26 prescriptive use of a header within the payload of us (DHS) know and we’ll gladly help to 

18 Type-1 a biometrics transaction. The Type 1 should redraft the text for this section to 

transact continue to be prescriptively specified for such discuss the need for supporting more ion biometric enrolment use cases. However there thoroughly supporting the decoupling of informat are other scenarios where other industry XML the message transaction layer and the ion headers serve as better solutions. data layers of the specification. record 

“Table 207 Type-1 transaction information record” 

RAY-2 P. 27 

Line 16 -22 

ge ed The used font size in this text body looks much bigger than the before and after paragraphs. The 

problem looks even more obviously in a printed out copy. 

This is a general problem through out the document. Suggest using a smaller courier font size that will blend in better. 

RAY-3 Tables 

207 vs. 210 P. 26 vs. 38 

ge ed 

What does Table 207 list all of the field numbers (column 3) but Table 210 list only few? 

SAB-3 [Starting 

at 209, Fields 1.005 and 1.015 – 

[p. 26 (37) and througho ut for date/tim e fields— 

Developers need to be well prepared to address 

the new XML DATE format changes when transitioning from the tag formats of DATE and GMT to the new proposed XML formats. The proposed XML date format has changed the 

Please clarify to the NIST reviewers that the XML version/format of the UTC is the version NIST is actively supporting on their time systems. If this is not the case then please consider creating a new field that includes what version/format 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

EMN] EMN] historical 8 numeric character YYYYMMDD format 

to the 10 character YYYY-MM-DD . (see historical tag 1.005 DAT). This "little change" can be a very expensive transition as the datasets transition through multiple systems. I am not adverse to this change since I believe it improves exchanging date information with date translation software easier than the current 8 numeric format, however this change needs to be managed well when exchanging data between the historical Tag formatted 8 characters to the XML 10 characters and vice verse, to avoid data corruption /truncation problems etc. The GMT (1.015) has been transitioned from the historical 15 character YYYYMMDDHHNNSSZ to a version of the UTC (Universal Coordinated Time) (1.015) YYYY-MM-DDThh:mm:ssZ. This also needs to be ready to be properly translated to avoid data corruption. The CBEFF element 99.005 is referencing the UTC (Coordinated Universal Time) format also but then states the abbreviation is UTS. This may be a typo since UTS stands for Smoothed Universal Time,?? 

of time is being used to generate the date/time stamp. With the parent child relationship. For 99.005: If they mean UTS then it should be Smoothed Universal Time. Please see defs below 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
ons: 

Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source 

& Comment 

Number 

(e.g. 

FBI-1) 

Section/ 

Clause/A 

nnex 

No. 

(e.g. 

1.1.1) 

Paragraph 

/ 

Figure/Ta 

ble/Note 

& Page 

No. 

(e.g. 

Typ 

e of 

com 

-

men 

t2 

Comment (justification for change) Proposed change 

 (provide proposed text to insert in 

document, if possible) 

Figure 1, 

p. 5) 

Contin 

Definiti

uation of colum n 6 from SAB-3 above TSC-1 Type 1 PackageInfo ed Name of the element is not intuitive; it does not reflect that Change element name to, e.g

Records rmationReco this element contains ANSI/NIST transaction information. PackageTransactionInformati

rd 

TSC-2 Type 1 Ansi- te Handled in ebXML (header info, cannot generate payload for Make this field an optional fie

Records nist:Transac multiple targets due to embedded transaction information) 

tionDate 

TSC-3 Type 1 

Records 

ansinist:Transac tionDestinat 

te Handled in ebXML (header info, cannot generate payload for 

multiple targets due to embedded transaction information) 

Make this field an optional fie

ionOrganizat ion 

TSC-4 Type 1 

Records 

ansinist:Transac te Handled in ebXML (header info, cannot generate payload for multiple targets due to embedded transaction information) Make this field an optional fie

tionOriginati ngOrganizati 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

on 

TSC-5 Type 1 

Records 

ansinist:Transac tionControlI dentificatio n 

te Handled in ebXML (header info, cannot generate payload for 

multiple targets due to embedded transaction information) 

Make this field an optional fie

TSC-6 Type 1 

Records 

ansinist:NativeS canningReso lutionValue 

te Specifically for devices Make this field an optional fie

TSC-7 Type 1 

Records 

ansinist:Nominal Transmitting ResolutionV alue 

te Specifically for devices Make this field an optional fie

TSC-8 Type 1 

Records 

ansinist:Transac tionMajorVe rsionValue 

Handled in ebXML (header info, cannot generate payload for 

multiple targets due to embedded transaction information) 

Make this field an optional fie

TSC-9 Type 1 

Records 

ansinist:Transac tionMinorVe rsionValue 

Handled in ebXML (header info, cannot generate payload for 

multiple targets due to embedded transaction information) 

Make this field an optional fie

TSC-10 Type 1 

Records 

ansinist:Transac tionPriorityV alue 

te Handled in ebXML (header info, cannot generate payload for 

multiple targets due to embedded transaction information) 

TSC-11 Type 1 

Records 

ansinist:Transac tionCategor yCode 

te Handled in ebXML (header info, cannot generate payload for 

multiple targets due to embedded transaction information) 

Make this field an optional fie

TSC-12 Type 1 ansi- te Redundant in message, not necessary in XML where each Make this field an optional fie

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source 

& Comment 

Number 

(e.g. 

FBI-1) 

Section/ 

Clause/A 

nnex 

No. 

(e.g. 

1.1.1) 

Paragraph 

/ 

Figure/Ta 

ble/Note 

& Page 

No. 

(e.g. 

Typ 

e of 

com 

-

men 

t2 

Comment (justification for change) Proposed change 

 (provide proposed text to insert in 

document, if possible) 

Figure 1, 

p. 5) 

Records nist:Transac 

tionContent Summary/an sinist:Content FirstRecordC ategoryCode 

record is typed 

TSC-13 Type 1 

Records 

ansinist:Transac tionContent Summary/an sinist:Content RecordCoun t 

te Redundant in message, not necessary in XML Make this field an optional fie

TSC-14 Type 1 

Records 

ansinist:Transac tionContent Summary/an sinist:Content RecordSum mary/ansinist:ImageR eferenceIde ntification 

te Redundant in message, not necessary in XML Make this field an optional fie

TSC-15 Type 1 

Records 

ansinist:Transac tionContent Summary/an sinist:Content 

te Redundant in message, not necessary in XML Make this field an optional fie

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

RecordSum mary/ansinist:RecordC ategoryCode 

DHS- 209.1.3.12 Line 8 on The passage below helps to describe the list of transaction If this comment is acceptable

OCIO- Element page 31 types supported by the standard. There is a need to use the we’ll gladly help to redraft th20 <ansinist:Transa 

ctionCateg oryCode> 

biometric modal data types in the standard decoupled from the standard. Perhaps an approach could be prescribed by with transactions types that are beyond the bounds of the existing use cases could still use the biometric data types— fingerprint, iris, facial, etc. 

the need for supporting more decoupling of the message trof the specification. 

“Cross reference: Part-1 Section 9.1.4 Field 1.004: Type of transaction (TOT) This mandatory element shall contain an identifier, which designates the type of transaction and subsequent processing that this file should be given. (Note: Type of Transaction shall be in accordance with definitions provided by the receiving agency.)” 

DHSOCIO21 

209.1.3.13 Element <ansinist:Transac tionContent Summary> 

Line 15 on page 31 Perhaps this part of the header could be linked to the ebMS 

Manifest object or the DOJ LEXS Digest object. “209.1.3.13 Element <ansinist:TransactionContentSummary>” 

If this comment is acceptablewe’ll gladly help to redraft ththe need for supporting more decoupling of the message trof the specification. We could 

other headers that could provtransaction but in other transjustice, counter terrorism, cocommunities. 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source 

& Comment 

Number 

(e.g. 

FBI-1) 

Section/ 

Clause/A 

nnex 

No. 

(e.g. 

1.1.1) 

Paragraph 

/ 

Figure/Ta 

ble/Note 

& Page 

No. 

(e.g. 

Typ 

e of 

com 

-

men 

t2 

Comment (justification for change) Proposed change 

 (provide proposed text to insert in 

document, if possible) 

Figure 1, 

p. 5) 

DHSOCIO22 This part of the message implies the existence of a Person data object without prescribing an approach to exchange such data in a NIEM structured format. This passage explains how 

represent the data in the Type 2 generic data structure, but does not enable the use of the NIEM definitions for these exact data structures. NIEM supports these structures and a deep Person model in its current NIEM 2.0 release. “ 210 Type-2 user-defined descriptive text record Type-2 logical records shall contain textual information relating to the subject of the exchange package and shall be represented in an ASCII format. This record may include such information as the state or FBI numbers, physical characteristics, demographic data, and the subject’s criminal history. Every exchange package usually contains one or more Type-2 records which is dependent upon the entry in the <ansinist:TransactionCategoryCode> element (Part-1 Type-ofTransaction, field 1.004, TOT). Table 209 lists the contents of the records. (This table has no equivalent in Part 1.)” 

If this comment is acceptablewe’ll gladly help to redraft than approach to maximize the definitions from NIEM when athe need to continue to suppstructured/unstructured defispecification. 

Daon-6 211.2.4 1st para., 

page 38 

ed 2nd sentence references “Type-13” record, but this section 

describes record types 3-6. 

Change “Type-13” to “Type 3

Daon-7 211.2.4.6 page 40 ed Missing a word in “This complex shall contain...” Change to “This complex elem

TSC-16 Type 3, 4, 

5, 6, 7, 8, 10, 13, 14, 15, 16, 17 and 99 

PackageIma geRecordTy pe 

te Logical record types 3, 4, 5, 6, 7, 8, 10, 13, 14, 115, 16, 17 

and 99 are all grouped under PackageImageRecordType. The system that processes the message won’t know whether this is a facial image or a fingerprint image, etc. until it goes through one more level. More clarity and efficiency may be achieved by providing separate high-level element for each logical record type. 

Providing separate high-level type. 

TSC-17 Type 10 

Records 

ansinist:FaceIm te For many of the facial records that TSC have, we only have the JPEG image with no image metadata other then those in Make this field an optional fie

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source Section/ Paragraph Typ Comment (justification for change) Proposed change 

& Comment 

Number 

Clause/A 

nnex 

No. 

/ 

Figure/Ta 

ble/Note 

e of 

com 

-

 (provide proposed text to insert in 

document, if possible) 

(e.g. 

FBI-1) 

(e.g. 

1.1.1) 

& Page 

No. 

(e.g. 

men 

t2 

Figure 1, 

p. 5) 

age/ansinist:ImageC aptureDetail /ansinist:Capture Date (PHD) 

the JPEG header. PHD is rarely present. Moreover, the data type requires a full date, TSC may only have a partial date. In other cases, the date information is classified and it cannot be distributed. 

TSC-18 Type 10 

Records 

ansinist:FaceIm age/ansinist:Capture Organization (SRC) 

te For many of the facial records that TSC have, we only have 

the JPEG image with no image metadata other then those in the JPEG header. SRC usually is not supplied due to its classified nature. 

Make this field an optional fie

TSC-19 Type 10 

Records 

te It appears from the spec that only JPEG and PNG files can be 

transported. What about lossless formats like gif? 

TSC-20 Type 10 

Records 

te Where can MIME type be specified? 

RAY-4 Table 221 

P. 78 

te Would it result in errors if using all lower cases or mixed of 

lower and upper cases for the attributes codes? 

RAY-5 Table 233 

P. 105 

ed Replace the current Italic font with a regular font. 

RAY-6 P. 118 

Line 27 - 29 

ge ed There are big space gaps between words or fields. For paragraphs like this, it m

instead of Justify. 

RAY-7 P. 165 ed The way of constructing the ASCII table looks very 

cumbersome and confused. 

RAY-8 P. 185 

Line 36 - 38 

te There is a ratio disproportion when looking at it in vertical 

direction. 

Add a space line between 37 (component 3) to the center 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10 
Comments on the March 2008 Draft of ANSI/NIST ITL 2-200X Date: April 7, 2008 

(1) (2) (3) (4) (5) (6) 

Source 

& Comment 

Number 

(e.g. 

FBI-1) 

Section/ 

Clause/A 

nnex 

No. 

(e.g. 

1.1.1) 

Paragraph 

/ 

Figure/Ta 

ble/Note 

& Page 

No. 

(e.g. 

Typ 

e of 

com 

-

men 

t2 

Comment (justification for change) Proposed change 

 (provide proposed text to insert in 

document, if possible) 

Figure 1, 

p. 5) 

RAY-9 P. 186 

Line 19 

ed There is a misalignment on this line or somewhere between 

the line 15 and 38. 

Daon = Daon DHS = Department of Homeland Security, US-VISIT/OCIO MNT = Mentalix RAY = Raytheon SAB = Saber TSC = Terrorist Screening Center 

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 

2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINONOTE Columns 1, 2, 4, 5 and 6 are compulsory. ISO electronic balloting commenting template/version 2001-10