Beschluss 2008/616/JI des Rates vom 23. Juni 2008 zur Durchführung des Beschlusses 2008/615/JI zur Vertiefung der grenzüberschreitenden Zusammenarbeit, insbesondere zur Bekämpfung des Terrorismus und der grenzüberschreitenden Kriminalität

Durchsuchbarer Text in vereinfachter Darstellung. Tabellen, Abbildungen und verbindliche Gestaltung bitte anhand der Originaldateien prüfen.

Entschlüsselung von E-Mails unter Einsatz von s/MIME und/oder OpenPGP. Es ist beabsichtigt, eine einzelne, leicht zu nutzende Schnittstelle für E-Mail-Clients bereitzustellen, die verschlüsselte E-Mails in den beiden geläufigsten E-Mail-Verschlüsselungsformaten verschicken und erhalten sollen. Daher genügen alle dem Stand der Technik entsprechenden Implementierungen der JavaMail-API den Anforderungen gemäß dem Beschluss 2008/615/JI, beispielsweise das Produkt Bouncy Castle JCE (Java Cryptographic Extension), das genutzt wird, um s/MIME für den Prototyp des DNA-Datenaustauschs zwischen allen Mitgliedstaaten zu implementieren. 5.5. Anwendungsarchitektur Jeder Mitgliedstaat stellt jedem anderen Mitgliedstaat einen Satz (Set) standardisierter DNA-Profildaten zur Verfügung, die dem aktuellen gemeinsamen ICD entsprechen. Dies kann entweder durch Bereitstellung einer logischen Sicht (logical view) der eigenen nationalen Datenbank erfolgen, oder aber durch Einrichtung einer physisch exportierten Datenbank (Indexdatenbank). Anhand der vier Hauptkomponenten — E-Mail Server/s/MIME, Anwendungsserver, Data Structure Area für den Abruf/die Eingabe von Daten und zur Registrierung der eingehenden/ausgehenden Nachrichten, sowie Match Engine — wird die gesamte Anwendungslogik anbieterunabhängig implementiert. Um allen Mitgliedstaaten eine unkomplizierte Integration der Komponente in ihre jeweiligen nationalen Standorte zu ermöglichen, wurde die festgelegte gemeinsame Funktionalität anhand von Open-Source-Komponenten implementiert, die von den einzelnen Mitgliedstaaten entsprechend ihrer jeweiligen nationalen IT-Politik und ihren Vorschriften ausgewählt werden können. Aufgrund der anbieterunabhängigen Merkmale, die zu implementieren sind, um Zugang zu den Indexdatenbanken mit den DNA-Profilen zu erhalten, die in den Anwendungsbereich des Beschlusses 2008/615/JI fallen, genießt jeder Mitgliedstaat Entscheidungsfreiheit bei der Wahl seiner Hardware und Software-Plattform, einschließlich der Datenbank- und Betriebssysteme. Für den DNA-Datenaustausch wurde ein Prototyp entwickelt und auf dem bestehenden gemeinsamen Netzwerk mit Erfolg getestet. Die Version 1.0 wurde in die Produktionsumgebung eingebunden und befindet sich im täglichen operativen Einsatz. Die Mitgliedstaaten können dieses gemeinsam entwickelte Produkt nutzen oder aber ihre eigenen Produkte entwickeln. Die gemeinsamen Produktkomponenten werden gewartet, bedarfsgerecht angepasst und entsprechend den im Wandel befindlichen informationstechnischen, forensischen bzw. polizeifachlichen Anforderungen weiterentwickelt. Abbildung 2: Überblick über die Anwendungstopologie Case 1 a logical view National env. Index Profile National env. Case 2 a physical DB Index DBMS Email server/sMIME Application server Data Structure (protocol) Match engine TESTA II 5.6. Für die Anwendungsarchitektur zu verwendende Protokolle und Standards 5.6.1. XML Für den DNA-Datenaustausch wird in vollem Umfang das XML-Schema verwendet, das den SMTP-E-Mail-Nachrichten als Attachment beigefügt wird. XML (eXtensible Markup Language) ist eine vom W3C empfohlene allgemeine Markup-Sprache (Bezeichnungssprache) zur Schaffung spezieller Markup-Sprachen, mit denen viele verschiedene Arten von Daten beschrieben werden können. Das für den Austausch zwischen allen Mitgliedstaaten geeignete DNA-Profil wird im ICD-Dokument anhand von XML und dem XML-Schema beschrieben. 5.6.2. ODBC Open DataBase Connectivity (ODBC) ist eine auf Standardsoftware gestützte API-Methode für den Zugang zu Datenbankverwaltungssystemen und macht sie unabhängig von Programmiersprachen, Datenbanken und Betriebssystemen. Allerdings hat ODBC auch einige Nachteile. Die Verwaltung einer großen Anzahl von Client-Maschinen kann dazu führen, dass eine Vielzahl von Treibern (Drivers) und DLL einbezogen werden. Diese Komplexität kann den mit der Systemverwaltung verbundenen Aufwand erhöhen. 5.6.3. JDBC Java DataBase Connectivity (JDBC) ist ein API für die Programmiersprache Java, die definiert, auf welche Weise ein Client Zugang zu einer Datenbank erhält. Im Gegensatz zu ODBC erfordert JDBC nicht die Verwendung eines bestimmten Satzes von lokalen DLL im Desktop. Die Geschäftslogik zur Bearbeitung von DNA-Profil-Anfragen und -Antworten an jedem Standort der Mitgliedstaaten veranschaulicht die folgende Zeichnung. Sowohl die bei einer Anfrage als auch bei einer Antwort generierten Datenflüsse interagieren mit einem neutralen Datenbereich, der unterschiedliche Datenpools mit einer gemeinsamen Datenstruktur umfasst. Abbildung 3: Übersicht über den Anwendungs-Workflow im Standort der einzelnen Mitgliedstaaten Request flow at each Member State site DB/Tab send fetch Protocol Profile Result (HIT/NO-HIT) fetch send Communication centre fetch Encrypted message Email server send send send TESTA II Encrypted network Reply flow at each Member State site National DNA DB Match engine Indexed DNA database fetch send DB/Tab Protocol Profile Result (HIT/NO-HIT) send fetch Communication centre fetch Encrypted message Email server send 5.7. Kommunikationsumgebung 5.7.1. Gemeinsames Kommunikationsnetzwerk: TESTA und seine Nachfolgeinfrastruktur Für den DNA-Austausch nutzte die Anwendung E-Mails — ein asynchroner Mechanismus — zur Übermittlung von Anfragen und zur Entgegennahme von Antworten zwischen den Mitgliedstaaten. Da alle Mitgliedstaaten zumindest einen nationalen Zugangspunkt zu dem TESTA-Netzwerk haben, wird dieses für den DNA-Datenaustausch genutzt. TESTA bietet mit seinem E-Mail-Relay eine Reihe von Mehrwertdiensten. Neben dem Hosting TESTA-spezifischer E-Mail-Boxen ist die Infrastruktur in der Lage, Mailing-Verteilerlisten und Routing-Regelungen (Routing Policies) zu implementieren. Damit kann TESTA als Clearingstelle für Nachrichten eingesetzt werden, die an Behörden innerhalb der EU-weiten Domäne adressiert sind. Es können auch Virenprüffunktionen eingerichtet werden. Das durch eine Firewall geschützte TESTA E-Mail-Relay ist auf einer Hardware-Plattform mit hoher Verfügbarkeit aufgebaut, die sich im zentralen Standort der TESTA-Anwendung befindet. Die Domänennamendienste DNS (Domain Name Services) lösen Namensbezeichnungen (Resource Locators) in IP-Adressen auf und verstecken Adressierungen vor den Benutzern oder Anwendungen. 5.7.2. Sicherheitserwägungen Im TESTA-Umfeld wurde das Konzept eines VPN (virtuelles privates Netzwerk) umgesetzt. Die für den Aufbau dieses VPN verwendete Tag-Switching-Technologie wird weiterentwickelt werden, um den IETF-Standard (Internet Engineering Task Force) MPLS (Multi-Protocol Label Switching) zu unterstützen. MPLS ist eine auf dem IETF-Standard basierende Technologie, die den Datenfluss im Netzwerk durch Vermeidung der Paketanalyse durch Zwischen-Router („Hops“) beschleunigt. Dies erfolgt auf der Grundlage so genannter Labels (Kennsätze), die durch Edge-Router des Backbones an das Datenpaket angehängt werden, auf der Basis der Informationen, die in der FIB (Forwarding Information Base) gespeichert sind. Labels werden auch zur Einrichtung virtueller privater Netze (VPNs) verwendet. MPLS kombiniert die Vorteile des Layer-3-Routing mit denen des Layer-2-Switching. Da IP-Adressen beim Durchlaufen des Backbones nicht evaluiert werden, werden von MPLS keine Beschränkungen für IP-Adressierung auferlegt. Darüber hinaus werden E-Mails im TESTA-Netzwerk durch einen s/MIME-gesteuerten Verschlüsselungsmechanismus geschützt. Ohne Schlüssel und das erforderliche Zertifikat können verschlüsselte Nachrichten in diesem Netzwerk nicht entschlüsselt werden. 5.7.3. Für das Kommunikationsnetzwerk zu verwendende Protokolle und Standards 5.7.3.1. SMTP Das SMTP-Protokoll (Simple Mail Transfer Protocol) ist De-Facto-Standard für die Übermittlung von E-Mails über das Internet. SMTP ist ein relativ einfaches, textbasiertes Protokoll, bei dem ein oder mehrere Empfänger einer Nachricht angegeben werden, woraufhin der Text der Nachricht übermittelt wird. SMTP verwendet den TCP-Port 25 entsprechend der IETF-Spezifikation. Zur Bestimmung des SMTP-Servers für einen bestimmten Domänennamen wird der MX-(Mail eXchange)-DNS-(Domain Name Systems)-Record verwendet. Da dieses Protokoll ursprünglich ausschließlich ASCII-textbasiert war, gab es Schwierigkeiten mit binären Dateien. Zur Aufbereitung binärer Dateien im Hinblick auf ihre Übermittlung durch SMTP wurden Standards wie MIME ausgearbeitet. Gegenwärtig unterstützen die meisten SMTP-Server die 8BITMIME- und s/MIME-Erweiterungen, so dass binäre Dateien fast ebenso einfach wie „Nur Text“ (plain text) übermittelt werden können. Die Arbeitsabläufe für s/MIME-Operationen werden im Abschnitt über s/MIME (siehe Kapitel 5.4) beschrieben. SMTP ist ein „Push“-Protokoll, d. h., es bietet nicht die Möglichkeit, auf Verlangen von einem Remote-Server Nachrichten abzurufen („pull“). Um dies zu ermöglichen, muss der Mail-Client POP3 oder IMAP benutzen. Es wurde beschlossen, zur Implementierung des DNA-Datenaustauschs das Protokoll POP3 zu verwenden. 5.7.3.2. POP Lokale E-Mail-Clients verwenden die Version 3 des Post Office Protocol (POP3), ein Internet-Standardprotokoll (der Anwendungsschicht), zum Abruf einer E-Mail von einem Remote-Server übe eine TCP/IP-Verbindung. Unter Verwendung des SMTP-Submit-Profils des SMTP-Protokolls können E-Mail-Clients Nachrichten über das Internet oder interne Firmennetze übermitteln. MIME bildet den Standard für Attachments und Nicht-ASCII-Texte bei der Übermittlung von E-Mails. Obgleich weder POP3 noch SMTP MIME-formatierte E-Mails benötigen, erfolgt der E-Mail-Verkehr im Internet im Wesentlichen MIME-formatiert, so dass POP-Clients in der Lage sein müssen, MIME zu verstehen und anzuwenden. Die gesamte Kommunikationsumgebung nach Beschluss 2008/615/JI wird daher die Komponenten des POP integrieren. 5.7.4. Zuweisung der Netzwerkadressen Operative Umgebung Die europäische IP-Registrierungsbehörde RIPE hat TESTA unlängst einen speziellen Subnet-Adressenblock der Klasse C zugewiesen. Erforderlichenfalls können TESTA künftig weitere Adressenblocks zugewiesen werden. Die Zuordnung von IP-Adressen an die Mitgliedstaaten erfolgt im Allgemeinen nach einem geografischen Schema in Europa. Der Datenaustausch zwischen Mitgliedstaaten im Rahmen des Beschlusses 2008/615/JI erfolgt im Wege eines EU-weiten logisch geschlossenen IP-Netzwerks. Testumgebung Damit allen angeschlossenen Mitgliedstaaten eine reibungslos funktionierende Operationsumgebung geboten werden kann, ist es erforderlich, für neue Mitgliedstaaten, die ihre Teilnahme an dem Datenaustausch vorbereiten, eine auf dem geschlossenen Netzwerk aufbauende Testumgebung zu schaffen. Es wurde eine Vorlage mit Parametern, darunter IP-Adressen, Netzeinstellungen, E-Mail-Domänen sowie Benutzerkonten, festgelegt, die in den betreffenden Standorten der Mitgliedstaaten eingerichtet werden sollten. Zudem wurde für Testzwecke ein Satz von „Pseudo“-DNA-Profilen erstellt. 5.7.5. Konfigurationsparameter Es wurde ein sicheres E-Mail-System auf der Grundlage der Domäne eu-admin.net eingerichtet. Diese Domäne und die assoziierten Adressen sind vor einem Zugriff durch Stellen außerhalb der EU-weiten TESTA-Domäne geschützt, da die betreffenden Namen nur dem zentralen DNS-Server von TESTA bekannt sind, der vom Internet abgeschirmt ist. Die Zuordnung (Mapping) dieser TESTA-Site-Adressen („host names“) zu den IP-Adressen wird vom TESTA-DNS-Dienst vorgenommen. Für jede lokale Domäne wird ein Mail-Eintrag in diesen zentralen DNS-Server von TESTA eingefügt, so dass alle an die lokalen TESTA-Domänen geschickten E-Mail-Nachrichten dem zentralen Mail-Relay von TESTA zugeleitet werden. Dieses zentrale Mail-Relay leitet sie dann anhand der E-Mail-Adressen der lokalen Domäne an den speziellen E-Mail-Server der lokalen Domäne weiter. Durch dieses Verfahren zur Übermittlung von E-Mails durchlaufen vertrauliche Informationen ausschließlich die EU-weite geschlossene Netzwerkinfrastruktur und nicht das unsichere Internet. In allen Standorten der Mitgliedstaaten ist es erforderlich, Subdomänen ( Fett- und Kursivdruck ) einzurichten, die der folgenden Syntax entsprechen: „ application-type.pruem.Member State-code. eu-admin.net“, wobei „ Member State-code “ den Wert des aus 2 Buchstaben zusammengesetzten Mitgliedstaatencodes annimmt (z. B. AT, BE usw.) und „ application-type “ einen der folgenden Werte annimmt: DNA und FP. In Anwendung der oben genannten Syntax erhalten die Subdomänen der Mitgliedstaaten folgende Form: MS Sub Domains Comments BE dna.pruem.be.eu-admin.net Setting up a secure local link to the existing TESTA II access point fp.pruem.be.eu-admin.net BG dna.pruem.bg.eu-admin.net fp.pruem.bg.eu-admin.net CZ dna.pruem.cz.eu-admin.net fp.pruem.cz.eu-admin.net DK dna.pruem.dk.eu-admin.net fp.pruem.dk.eu-admin.net DE dna.pruem.de.eu-admin.net Using the existing TESTA II national access points fp.pruem.de.eu-admin.net EE dna.pruem.ee.eu-admin.net fp.pruem.ee.eu-admin.net IE dna.pruem.ie.eu-admin.net fp.pruem.ie.eu-admin.net EL dna.pruem.el.eu-admin.net fp.pruem.el.eu-admin.net ES dna.pruem.es.eu-admin.net Using the existing TESTA II national access point fp.pruem.es.eu-admin.net FR dna.pruem.fr.eu-admin.net Using the existing TESTA II national access point fp.pruem.fr.eu-admin.net IT dna.pruem.it.eu-admin.net fp.pruem.it.eu-admin.net CY dna.pruem.cy.eu-admin.net fp.pruem.cy.eu-admin.net LV dna.pruem.lv.eu-admin.net fp.pruem.lv.eu-admin.net LT dna.pruem.lt.eu-admin.net fp.pruem.lt.eu-admin.net LU dna.pruem.lu.eu-admin.net Using the existing TESTA II national access point fp.pruem.lu.eu-admin.net HU dna.pruem.hu.eu-admin.net fp.pruem.hu.eu-admin.net MT dna.pruem.mt.eu-admin.net fp.pruem.mt.eu-admin.net NL dna.pruem.nl.eu-admin.net Intending to establish a new TESTA II access point at the NFI fp.pruem.nl.eu-admin.net AT dna.pruem.at.eu-admin.net Using the existing TESTA II national access point fp.pruem.at.eu-admin.net PL dna.pruem.pl.eu-admin.net fp.pruem.pl.eu-admin.net PT dna.pruem.pt.eu-admin.net …… fp.pruem.pt.eu-admin.net …… RO dna.pruem.ro.eu-admin.net fp.pruem.ro.eu-admin.net SI dna.pruem.si.eu-admin.net ...… fp.pruem.si.eu-admin.net ....... SK dna.pruem.sk.eu-admin.net fp.pruem.sk.eu-admin.net FI dna.pruem.fi.eu-admin.net [To be inserted] fp.pruem.fi.eu-admin.net SE dna.pruem.se.eu-admin.net fp.pruem.se.eu-admin.net UK dna.pruem.uk.eu-admin.net fp.pruem.uk.eu-admin.net KAPITEL 2: Austausch daktyloskopischer Daten (Schnittstellenkontrolldokument) Mit dem folgenden Schnittstellenkontrolldokument sollen die Anforderungen für den Austausch daktyloskopischer Daten zwischen den Automatisierten Fingerabdruck-Identifizierungs-Systemen (AFIS) der Mitgliedstaaten festgelegt werden. Es stützt sich auf die Interpol-Implementierung des ANSI/NIST-ITL 1-2000-Standards (INT-I, Version 4.22b). In dieser Fassung werden alle grundlegenden Definitionen für Datensätze der Typen Typ 1, Typ 2, Typ 4, Typ 9, Typ 13 und Typ 15 erfasst, die für eine Fingerabdruckverarbeitung erforderlich sind, die sich auf Bilder und Minutien stützt. 1. Übersicht über den Dateiinhalt Eine Fingerabdruckdatei besteht aus verschiedenen logischen Datensätzen. Im ursprünglichen ANSI/NIST-ITL 1-2000-Standard gibt es 16 Typen von Datensätzen. Zwischen den Datensätzen und zwischen den Feldern und Unterfeldern innerhalb der Datensätze werden geeignete ASCII-Trennzeichen verwendet. Nur 6 Datensatz-Typen werden für den Informationsaustausch zwischen der Sendestelle und der Empfangsstelle verwendet: Typ 1 -> Transaktionsinformationen Typ 2 -> Alphanumerische Personen-/Falldaten Typ 4 -> Hochauflösende Fingerabdruckbilder in Grautönen Typ 9 -> Minutiendatensätze Typ 13 -> Datensatz mit Bildern von Fingerabdruck- und Handflächenabdruckspuren in variabler Auflösung Typ 15 -> Datensatz mit Bildern von Handflächenabdrücken in variabler Auflösung 1.1. Typ 1 — File Header Dieser Datensatz enthält Routing-Informationen und Informationen zur Beschreibung der Struktur der übrigen Datei. In dieser Datensatzart werden ferner die Transaktionstypen definiert, die unter die folgenden Kategorien fallen: 1.2. Typ 2 — Descriptive Text Dieser Datensatz enthält Textinformationen, die für die Sende- und die Empfangsstellen von Interesse sind. 1.3. Typ 4 — High Resolution Gray-scale Image Dieser Datensatz dient zum Austausch hochauflösender Fingerabdruckbilder (500 Pixel/Inch) in Graustufen (8 Bit). Die Fingerabdruckbilder werden mit dem WSQ-Algorithmus in einem Verhältnis von nicht mehr als 15:1 komprimiert. Andere Algorithmen für die Komprimierung oder nichtkomprimierte Bilder dürfen nicht verwendet werden. 1.4. Typ 9 — Minutiæ Record Typ-9-Datensätze dienen zum Austausch von Merkmalen der Papillarlinien oder Minutien. Mit diesen Datensätzen wird zum einen bezweckt, eine unnötige Doppelung von AFIS-Kodierungsprozessen zu vermeiden, und zum anderen, die Übertragung von AFIS-Codes, die weniger Daten enthalten als die entsprechenden Bilder, zu ermöglichen. 1.5. Typ 13 — Variable-Resolution Latent Image Record Diese Datensätze werden verwendet, um Fingerabdruckspuren und Handflächenabdruckspuren in variabler Auflösung zusammen mit alphanumerischen Textinformationen zu übermitteln. Die Scan-Auflösung der Bilder beträgt 500 Pixel/Inch mit 256 Graustufen. Wenn die Qualität des Spurenbildes dafür ausreicht, wird es mit einem WSQ-Algorithmus komprimiert. Erforderlichenfalls kann die Bildauflösung durch bilaterale Vereinbarung auf mehr als 500 Pixel/Inch und mehr als 256 Graustufen ausgeweitet werden. Für diesen Fall wird dringend empfohlen, JPEG-2000 zu verwenden (siehe Anlage 7). 1.6. Typ 15 — Variable-Resolution Palmprint Image Record Datensätze mit nummerierten Feldern werden verwendet, um Handabdruckbilder in variabler Auflösung zusammen mit alphanumerischen Textinformationen auszutauschen. Die Scan-Auflösung der Bilder beträgt 500 Pixel/Inch mit 256 Graustufen. Für ein möglichst geringes Datenaufkommen werden alle Handabdruckbilder mit einem WSQ-Algorithmus komprimiert. Erforderlichenfalls kann die Bildauflösung durch bilaterale Vereinbarung auf mehr als 500 Pixel/Inch und mehr als 256 Graustufen ausgeweitet werden. Für diesen Fall wird dringend empfohlen, JPEG-2000 zu verwenden (siehe Anlage 7). 2. Datensatz-Format Eine Transaktionsdatei besteht aus einem oder mehreren logischen Datensätzen. Für jeden Datensatz in der Datei müssen mehrere für den Datensatztyp geeignete Informationsfelder vorhanden sein. Jedes Informationsfeld kann ein oder mehrere grundlegende Informationselemente mit einheitlichem Wert enthalten. Zusammen werden diese Elemente verwendet, um unterschiedliche Aspekte der in dem Feld enthaltenen Daten deutlich zu machen. Ein Informationsfeld kann auch aus einem oder mehreren Informationselementen bestehen, die zusammengruppiert und innerhalb eines Felds mehrfach wiederholt werden. Eine solche Gruppe von Informationselementen ist als Unterfeld bekannt. Ein Informationsfeld kann somit aus einem oder mehreren Unterfeldern mit Informationselementen bestehen. 2.1. Informationstrennzeichen (Information Separators) In den Datensätzen mit nummerierten Feldern wird die Abgrenzung der Informationen durch 4 ASCII-Informationstrennzeichen erreicht. Bei den voneinander abgegrenzten Informationen kann es sich um Elemente innerhalb eines Felds oder Unterfelds, um Felder innerhalb eines Datensatzes oder um mehrfach vorkommende Unterfelder handeln. Diese Informationstrennzeichen sind im ANSI-Standard X3.4 definiert. Die Zeichen werden verwendet, um Informationen logisch voneinander abzugrenzen und festzulegen. In einem hierarchischen Bezug betrachtet ist das Dateitrennzeichen „FS“ (File Separator) das umfassendste Trennzeichen, gefolgt vom Gruppentrennzeichen „GS“ (Group Separator), dem Datensatztrennzeichen „RS“ (Record Separator) und schließlich dem Einheitentrennzeichen „US“ (Unit Separator). In Tabelle 1 sind diese ASCII-Trennzeichen und eine Beschreibung ihrer Verwendung in dem vorliegenden Standard enthalten. Informationstrennzeichen sind ihrer Funktion nach als Angabe der darauf folgenden Datenart zu sehen. Das Zeichen „US“ grenzt einzelne Informationselemente innerhalb eines Felds oder Unterfelds voneinander ab. Es zeigt an, dass das nächste Informationselement Bestandteil der Daten dieses Felds oder Unterfelds ist. Bei mehrfachen Unterfeldern innerhalb eines Felds, die durch das Zeichen „RS“ voneinander abgegrenzt werden, wird mit dem Zeichen der Beginn der nächsten Gruppe sich wiederholender Informationselemente angezeigt. Das Trennzeichen „GS“, das zwischen Informationsfeldern verwendet wird, zeigt den Beginn eines neuen Felds vor der Feldidentifizierungsnummer an, die erscheinen soll. Auf die gleiche Weise wird der Beginn eines neuen Datensatzes durch das Trennzeichen „FS“ angezeigt. Die 4 Zeichen haben nur eine Bedeutung, wenn sie als Trennzeichen für Datenelemente in den Feldern der ASCII-Textrecords verwendet werden. Die Trennzeichen haben in binären Bilddatensätzen und binären Feldern keine besondere Bedeutung, sie gehören lediglich zu den ausgetauschten Daten. Normalerweise sollte es keine leeren Felder oder Informationselemente geben, daher sollte zwischen allen Datenelementen lediglich ein Trennzeichen stehen. Die Ausnahme von dieser Regel liegt vor, wenn die Daten in Feldern oder Informationselemente in einer Transaktion nicht verfügbar sind, fehlen oder fakultativ sind und die Transaktion nicht davon abhängt, ob diese spezifischen Daten vorhanden sind. In diesen Fällen erscheinen mehrfache und nebeneinander liegende Trennzeichen zusammen; es is