natgillin/translations-raw huggingface dataset:
Další záznamy typu 15 – zobrazení otisku dlaně s proměnlivým rozlišením
Additional Type-15 variable-resolution palmprint image records
Soubor může obsahovat další záznamy typu 15.
Additional Type-15 records may be included in the file.
Pro každé další zobrazení otisku dlaně je nezbytný úplný logický záznam typu 15 s oddělovačem „FS“.
For each additional palmprint image, a complete Type-15 logical record together with the ‘FS’ separator is required.
Tabulka 11: Maximální množství kandidátů přijatých k ověření na jeden přenos
Table 11: Maximum numbers of candidates accepted for verification per transmission
Typy vyhledávání:
Search types:
TP/TP: porovnávání sad otisků deseti prstů (ten-print against ten-print)
TP/TP: ten-print against ten-print
LT/TP: porovnávání latentního otisku prstu se sadou otisků deseti prstů (fingerprint latent against ten-print)
LT/TP: fingerprint latent against ten-print
LP/PP: porovnávání latentního otisku dlaně s otiskem dlaně (palmprint latent against palmprint)
LP/PP: palmprint latent against palmprint
TP/UL: porovnávání sady otisků deseti prstů s nevyřešeným latentním otiskem prstu (ten-print against unsolved fingerprint latent)
TP/UL: ten-print against unsolved fingerprint latent
LT/UL: porovnávání latentního otisku prstu s nevyřešeným latentním otiskem prstu (fingerprint latent against unsolved fingerprint latent)
LT/UL: fingerprint latent against unsolved fingerprint latent
PP/ULP: porovnávání otisku dlaně s nevyřešeným latentním otiskem dlaně (palmprint against unsolved palmprint latent)
PP/ULP: palmprint against unsolved palmprint latent
LP/ULP: porovnávání latentního otisku dlaně s nevyřešeným latentním otiskem dlaně (palmprint latent against unsolved palmprint latent)
LP/ULP: palmprint latent against unsolved palmprint latent
Dodatek 1 ASCII kódy oddělovačů
Appendix 1 ASCII Separator Codes
Dodatek 2 Výpočet alfanumerického kontrolního znaku
Appendix 2 Calculation of Alpha-Numeric Check Character
Pro TCN a TCR (pole 1.09 a 1.10):
For TCN and TCR (Fields 1.09 and 1.10):
Číslo odpovídající kontrolnímu znaku se získá pomocí následujícího vzorce:
The number corresponding to the check character is generated using the following formula:
(RR * 108 + SSSSSSSS) Modulo 23
(YY * 108 + SSSSSSSS) Modulo 23
Znak RR představuje numerickou hodnotu posledních dvou číslic roku a znak SSSSSSSS numerickou hodnotu sériového čísla.
Where YY and SSSSSSSS are the numerical values of the last two digits of the year and the serial number respectively.
Kontrolní znak je pak odvozen z referenční tabulky uvedené níže.
The check character is then generated from the look-up table given below.
Pro CRO (pole 2.010)
For CRO (Field 2.010)
(RR* 106 + NNNNNN) Modulo 23
(YY * 106 + NNNNNN) Modulo 23
Znak RR představuje numerickou hodnotu posledních dvou číslic roku a znak NNNNNN numerickou hodnotu sériového čísla.
Where YY and NNNNNN are the numerical values of the last two digits of the year and the serial number respectively.
Referenční tabulka kontrolních znaků
Check Character Look-up Table
Dodatek 3 Znakové kódy
Appendix 3 Character Codes
7bitový kód ANSI pro výměnu informací
7-bit ANSI code for information interchange
Dodatek 4 Přehled operací
Appendix 4 Transaction Summary
Záznam typu 1 (povinný)
Type 1 Record (mandatory)
Ve sloupci podmínek:
Under the Condition Column:
O = nepovinné; M = povinné; C = podmíněné, pokud je operace odpovědí původní agentuře
O = Optional; M = Mandatory; C = Conditional if transaction is a response to the origin agency
Záznam typu 2 (povinný)
Type 2 Record (mandatory)
O = nepovinné; M = povinné; C = podmíněné, pokud jsou údaje k dispozici
O = Optional; M = Mandatory; C = Conditional if data is available
pokud je přenos dat v souladu s vnitrostátními právními předpisy (nevztahuje se na něj rozhodnutí 2008/615/SVV)
if the transmission of the data is in accordance with national law (not covered by the Council Decision 2008/615/JHA)
Dodatek 5 Definice záznamu typu 1
Appendix 5 Type-1 Record Definitions
1.013: INT-IUS4.22GS
INT-IUS4,22GS
Ve sloupci podmínek: O = nepovinné, M = povinné, C = podmíněné
Under the Condition Column: O = Optional, M = Mandatory, C = Conditional
Ve sloupci znakového typu: A = alfa, N = numerický, B = binární
Under the Character Type Column: A = Alpha, N = Numeric, B = Binary
1* povolené znaky pro název agentury jsou [„0.9“, „A.Z“, „a.z“, „_“,“.“, „ „, „-“]
1* allowed characters for agency name are [‘0..9’, ‘A..Z’, ‘a..z’, ‘_’, ‘.’, ‘’, ‘-’]
Dodatek 6 Definice záznamu typu 2
Appendix 6 Type-2 Record Definitions
Tabulka A.6.1: Operace CPS a PMS
Table A.6.1: CPS- and PMS-Transaction
Tabulka A.6.2: Operace SRE
Table A.6.2: SRE-Transaction
Tabulka A.6.3: Operace ERR
Table A.6.3: ERR-Transaction
Tabulka A.6.4: Operace MPS a MMS
Table A.6.4: MPS- and MMS-Transaction
1* povolené znaky jsou [„0.9“, „A.Z“, „a.z“, „_“,“.“, „ „, „-“, „ „]
1* allowed characters are [‘0..9’, ‘A..Z’, ‘a..z’, ‘_’, ‘.’, ‘’, ‘-’,‘,’]
Dodatek 7 Komprimační kódy pro data ve stupních šedi
Appendix 7 Greyscale Compression Codes
Komprimační kódy
Compression Codes
Wavelet Scalar Quantization Grayscale Fingerprint Image Compression Specification
Wavelet Scalar Quantisation Greyscale Fingerprint Image Compression Specification
IAFIS-IC-0010(V3), dated December 19, 1997
IAFIS-IC-0010(V3), dated 19 December 1997
Algorithm to be used for the compression of grayscale images in Type-4, Type-7 and Type-13 to Type-15 records.
Algorithm to be used for the compression of greyscale images in Type-4, Type-7 and Type-13 to Type-15 records.
To be used for lossy and losslessly compression of grayscale images in Type-13 to Type-15 records.
To be used for lossy and losslessly compression of greyscale images in Type-13 to Type-15 records.
Dodatek 8 Upřesnění zprávy
Appendix 8 Mailspecification
V zájmu zlepšení vnitřního fungování systému by měl být v předmětu zprávy operace podle Prümské smlouvy uveden kód země (CC) daného členského státu, který zprávu posílá, a typ operace (TOT pole 1.004).
To improve the internal workflow the mailsubject of a PRUEM transaction has to be filled with the country code (CC) of the Member State that send the message and the Type of Transaction (TOT Field 1.004).
Formát: Kód země/typ operace
Format: CC/type of transaction
Příklad: „DE/CPS“
Example: ‘DE/CPS’
Část pro obsah zprávy může zůstat prázdná.
The mailbody can be empty.
Definice povinných datových prvků a nepovinných datových prvků podle čl. 16 odst. 4 zní takto:
The definitions of mandatory data elements and optional data elements set out in Article 16(4) are as follows:
Povinné (M):
Mandatory (M):
Datové prvky musí být sděleny, pokud jsou informace k dispozici v národním registru členského státu.
The data element has to be communicated when the information is available in a Member State's national register.
Výměna informací je tedy povinná, pokud jsou tyto informace k dispozici.
Therefore there is an obligation to exchange the information when available.
Nepovinné (O):
Optional (O):
Datové prvky mohou být sděleny, pokud jsou informace dostupné v národním registru členského státu.
The data element may be communicated when the information is available in a Member State's national register.
Výměna informací tedy není povinná, ani když jsou informace k dispozici.
Therefore there is no obligation to exchange the information even when the information is available.
Pokud je prvek určen jako významný z hlediska rozhodnutí 2008/615/SVV, je každý takový prvek v souboru údajů označen (Y).
An indication (Y) is given for each element in the data set where the element is specifically identified as important in relation with the Decision 2008/615/JHA.
Spuštění vyhledávání
Triggers for the search
Existují dva různé způsoby pro vyhledávání těchto informací uvedené v následujícím odstavci:
There are two different ways to search for the information as defined in the next paragraph:
podle čísla podvozku (VIN), referenčního data a času (nepovinné),
by Chassis Number (VIN), Reference Date and Time (optional),
podle státní poznávací značky, čísla podvozku (VIN) (nepovinné), referenčního data a času (nepovinné).
by License Plate Number, Chassis Number (VIN) (optional), Reference Date and Time (optional).
Pomocí těchto kritérií pro vyhledávání budou oznámeny informace o jednom vozidle, a někdy i o více vozidlech.
By means of these search criteria, information related to one and sometimes more vehicles will be returned.
Pokud mají být oznámeny informace pouze o jednom vozidlu, všechny položky jsou oznámeny v jedné odpovědi.
If information for only one vehicle has to be returned, all the items are returned in one response.
Je-li nalezeno více vozidel než jedno, dožádaný členský stát může sám určit, které položky oznámí; všechny položky, nebo pouze položky pro upřesnění vyhledávání (například z důvodu ochrany soukromí nebo z důvodů týkajících se provedení).
If more than one vehicle is found, the requested Member State itself can determine which items will be returned; all items or only the items to refine the search (e.g. because of privacy reasons or because of performance reasons).
Položky nutné k upřesnění vyhledávání jsou uvedeny v bodě 1.2.2.1.
The items necessary to refine the search are pictured in paragraph 1.2.2.1.
V bodě 1.2.2.2 je popsán úplný soubor informací.
In paragraph 1.2.2.2 the complete information set is described.
Provádí-li se vyhledávání podle čísla povozku a referenčního data a času, může toto vyhledávání provádět jeden nebo všechny zúčastněné členské státy.
When the search is done by Chassis Number, Reference Date and Time, the search can be done in one or all of the participating Member States.
Provádí-li se vyhledávání podle čísla řidičského průkazu a referenčního data a času, musí ho provádět jeden konkrétní členský stát.
When the search is done by License Number, Reference Data and Time, the search has to be done in one specific Member State.
Obvykle se při vyhledávání používá skutečné datum a čas, je však možné provádět vyhledávání na základě referenčního data a času v minulosti.
Normally the actual Date and Time is used to make a search, but it is possible to conduct a search with a Reference Date and Time in the past.
Provádí-li se vyhledávání na základě referenčního data a času v minulosti a informace z minulých let nejsou v registru konkrétního členského státu k dispozici, protože žádné takové informace vůbec nejsou registrovány, lze poskytnout aktuální informace a uvést, že se jedná o aktuální informace.
When a search is made with a Reference Date and Time in the past and historical information is not available in the register of the specific Member State because no such information is registered at all, the actual information can be returned with an indication that the information is actual information.
Soubor údajů
Data set
Položky k upřesnění vyhledávání, které mají být oznámeny
Items to be returned necessary for the refinement of the search
[5]) e.g. Ford, Opel, Renault etc.
[5]) e.g. Ford, Opel, Renault, etc.
mopeds, motorbikes, cars etc.
mopeds, motorbikes, cars, etc.
Úplný soubor údajů
Complete data set
Registration holders’ (company) name
Registration holders' (company) name
and the name in printable format will be communicated
separate fields will be used for surname, infixes, titles, etc., and the name in printable format will be communicated
and the name in printable format will be communicated
separate fields for first name(s) and initials will be used, and the name in printable format will be communicated
separate fields will be used for Street, House number and Annex, Zip code, Place of residence, Country of residence etc.,
separate fields will be used for Street, House number and Annex, Zip code, Place of residence, Country of residence, etc., and the Address in printable format will be communicated
the Address in printable format will be communicated Y
Gender
individual, association, company, firm etc.
individual, association, company, firm, etc.
is the vehicle owner
is the vehicle owner,
is not the vehicle owner
is not the vehicle owner,
is not identified by the registration certificate as being the vehicle owner
is not identified by the registration certificate as being the vehicle owner.
Owners’ (company) name
Owners' (company) name
Ford, Opel, Renault etc.
e.g. Ford, Opel, Renault, etc.
Focus, Astra, Megane
e.g. Focus, Astra, Megane.
date of first registration of the vehicle somewhere in the world
Date of first registration of the vehicle somewhere in the world.
Date of the registration to which the specific certificate of the vehicle refers
Date of the registration to which the specific certificate of the vehicle refers.
scrapped, stolen, exported etc.
Scrapped, stolen, exported, etc.
regular, transito etc.
Regular, transito, etc.
The first unique document ID as printed on the vehicle document
The first unique document ID as printed on the vehicle document.
Softwarová aplikace EUCARIS předává zabezpečené sdělení ostatním členským státům a komunikuje se záložními předřazenými systémy členských států za pomoci XML.
The Eucaris software application handles secure communication to the other Member States and communicates to the back-end legacy systems of Member States using XML.
Členské státy si vyměňují zprávy tak, že je přímo zasílají příjemci.
Member States exchange messages by directly sending them to the recipient.
Datové centrum členského státu je propojeno se sítí Evropské unie TESTA.
The data centre of a Member State is connected to the TESTA network of EU.
Zprávy XML posílané přes tuto síť jsou kódovány.
The XML-messages sent over the network are encrypted.
Metoda používaná ke kódování těchto zpráv je SSL.
The technique to encrypt these messages is SSL.
Zprávy zasílané do záložních systémů jsou zprávy ve formátu XML v podobě prostého textu, jelikož spojení mezi aplikací a záložním systémem musí probíhat ve chráněném prostředí.
The messages sent to the back-end are plain text XML-messages since the connection between the application and the back-end shall be in a protected environment.
Je k dispozici klientská aplikace, kterou lze používat v rámci členského státu pro hledání ve vlastním registru nebo v registrech jiných členských států.
A client application is provided which can be used within a Member State to query their own register or other Member States' registers.
Klienti budou rozpoznáni na základě uživatelského jména a hesla nebo klientského certifikátu.
The clients will be identified by means of user-id/password or a client certificate.
Spojení s uživatelem může být kódováno, avšak odpovědnost za takové kódování nese každý členský stát.
The connection to a user may be encrypted, but this is the responsibility of each individual Member State.
Bezpečnostní prvky týkající se výměny zpráv
Security Features related to message exchange
Model zabezpečení je založen na kombinaci protokolu HTTPS a podpisu XML.
The security design is based on a combination of HTTPS and XML signature.
Tato alternativa využívá podpis XML k označení všech zpráv odeslaných na server a lze tak ověřit odesílatele zprávy zkontrolováním podpisu.
This alternative uses XML-signature to sign all messages sent so the server and can authenticate the sender of the message by checking the signature.
SSL s jednostranným ověřováním (pouze serverový certifikát) se používá k zajištění důvěrnosti a celistvosti zprávy při přenosu a zajišťuje ochranu proti napadení v podobě vymazání nebo opakování a vložení.
1-sided SSL (only a server certificate) is used to protect the confidentiality and integrity of the message in transit and provides protection against deletion/replay and insertion attacks.
Namísto vývoje zakázkového softwaru s cílem zavést SSL s oboustranným ověřováním se zavádí podpis XML.
Instead of bespoke software development to implement 2-sided SSL, XML-signature is implemented.
Použití podpisu XML se více blíží plánu vývoje internetových služeb než oboustranné zabezpečení SSL, a proto je strategičtější.
Using XML-signature is closer to the web services roadmap than 2-sided SSL and therefore more strategic.
Podpis XML lze používat několika způsoby, ale zvoleným přístupem je používat jej jako součást zabezpečení internetových služeb (WSS).
The XML-signature can be implemented in several ways but the chosen approach is to use XML Signature as part of the Web Services Security (WSS).
WSS určuje způsob, jak podpis XML používat.
WSS specifies how to use XML-signature.
Jelikož WSS vychází ze standardního protokolu SOAP, je logické tento standard co nejvíce podporovat.
Since WSS builds upon the SOAP standard, it is logical to adhere to the SOAP standard as much as possible.
Ověření uživatelů
Authentication of users
Uživatelé internetové aplikace Eucaris jsou ověřováni na základě uživatelského jména a hesla.
The users of the Eucaris web application authenticate themselves using a username and password.
Protože se používá standardní ověřování systému Windows, mohou členské státy v případě potřeby zvýšit úroveň ověření prostřednictvím použití klientských certifikátů.
Since standard Windows authentication is used, Member States can enhance the level of authentication of users if needed by using client certificates.
Uživatelské role
User roles
Softwarová aplikace Eucaris podporuje různé uživatelské role.
The Eucaris software application supports different user roles.
Každá skupina služeb má vlastní povolení.
Each cluster of services has its own authorisation.
Například (výhradní) uživatelé funkční skupiny „Smlouva o systému Eucaris“ nemohou využívat funkční skupinu „Prümská smlouva“.
E.g. (exclusive) users of the ‘“Treaty of Eucaris” — functionality’ may not use the ‘“Prüm” — functionality’.
Služby správce jsou od obvyklých rolí koncového uživatele odděleny.
Administrator services are separated from the regular end-user roles.
Záznam a vysledování výměny zpráv
Logging and tracing of message exchange
Softwarová aplikace EUCARIS usnadňuje záznam všech typů zpráv.
Logging of all message types is facilitated by the Eucaris software application.
Funkce správce umožňuje národnímu správci určit, které zprávy jsou zaznamenávány: žádosti od koncových uživatelů, příchozí žádosti od jiných členských států, informace poskytnuté národními registry apod.
An administrator function allows the national administrator to determine which messages are logged: requests from end-users, incoming requests from other Member States, provided information from the national registers, etc.
Aplikaci lze nastavit tak, aby byla k tomuto zaznamenávání využívána vnitřní nebo vnější (Oracle) databáze.
The application can be configured to use an internal database for this logging, or an external (Oracle) database.
Rozhodnutí o tom, jaké zprávy mají být zaznamenány, zjevně závisí na možnostech zaznamenávání jinde v předřazeném systému a připojených klientských aplikacích.
The decision on what messages have to be logged clearly depends on logging facilities elsewhere in the legacy systems and connected client applications.
Záhlaví každé zprávy obsahuje informace o žádajícím členském státu, žádající organizaci v rámci tohoto členského státu a zúčastněném uživateli.
The header of each message contains information on the requesting Member State, the requesting organisation within that Member State and the user involved.
Je uveden rovněž důvod žádosti.
Also the reason of the request is indicated.
Na základě společného zaznamenávání v žádajícím i odpovídajícím členském státě je možné úplné vysledování jakékoliv výměny zpráv (například o žádosti zúčastněného uživatele).
By means of the combined logging in the requesting and responding Member State complete tracing of any message exchange is possible (e.g. on request of a citizen involved).
Zaznamenávání nastavuje webový klient Eucarisu (menu Administration, Logging configuration).
Logging is configured through the Eucaris web client (menu Administration, Logging configuration).
Funkci zaznamenávání vykonává ústřední systém (Core http).
The logging functionality is performed by the Core System.
Pokud je zaznamenávání povoleno, celá zpráva (záhlaví a hlavní část) je uložena do jednoho záznamového registru.
When logging is enabled, the complete message (header and body) is stored in one logging record.
Pro každou definovanou službu a každý druh zprávy, který prochází ústředním systém, lze nastavit záznamovou úroveň.
Per defined service, and per message type that passes along the Core System, the logging level can be set.
Záznamové úrovně
Logging Levels
Možnosti záznamových úrovní jsou tyto:
The following logging levels are possible:
Důvěrná – zpráva je zaznamenána: Záznam NENÍ k dispozici pro službu vypisování záznamů, ale je k dispozici pouze na vnitrostátní úrovni pro potřeby auditu a řešení problémů.
Private — Message is logged: The logging is NOT available to the extract logging service but is available on a national level only, for audits and problem solving.
Žádná – zpráva není vůbec zaznamenána.
None — Message is not logged at all.
Druhy zpráv
Message Types
Výměna informací mezi členskými státy sestává z několika zpráv, jež jsou schematicky znázorněny na níže uvedeném obrázku.
Information exchange between Member States consists of several messages, of which a schematic representation is given in the figure below.
Možnosti druhů zpráv (na obrázku znázorněny jako ústřední systém (Core http) Eucarisu členského státu X jsou tyto:
The possible message types (in the figure shown for the Eucaris Core System of Member State X) are the following:
Request to Core http_Request message by Client
Request to Core System_Request message by Client
Request to Other Member State_Request message by Core http of this Member State
Request to Other Member State_Request message by Core System of this Member State
Request to Core http of this Member State_Request message by Core http of other Member State
Request to Core System of this Member State_Request message by Core System of other Member State
Request to Legacy Register_Request message by Core http
Request to Legacy Register_Request message by Core System
Request to Core http_Request message by Legacy Register
Request to Core System_Request message by Legacy Register
Response from Core http_Request message by Client
Response from Core System_Request message by Client
Response from Other Member State_Request message by Core http of this Member State
Response from Other Member State_Request message by Core System of this Member State
Response from Core http of this Member State_Request message by other Member State
Response from Core System of this Member State_Request message by other Member State
Response from Legacy Register_Request message by Core http
Response from Legacy Register_Request message by Core System
Response from Core http_Request message by Legacy Register
Response from Core System_Request message by Legacy Register
Na obrázku jsou znázorněny tyto výměny informací:
The following information exchanges are shown in the figure:
Žádost o informace z členského státu X členskému státu Y – modré šipky.
Information request from Member State X to Member State Y — blue arrows.
Tato žádost a odpověď jsou tvořeny druhy zprávy 1, 2, 7 a 6.
This request and response consists of message types 1, 2, 7 and 6, respectively,
Žádost o informace z členského státu Z členskému státu X – červené šipky.
Information request from Member State Z to Member State X — red arrows.
Tato žádost a odpověď jsou tvořeny druhy zprávy 3, 4, 9 a 8.
This request and response consists of message types 3, 4, 9 and 8, respectively,
Žádost o informace z předřazeného registru ústřednímu systému (tato cesta zahrnuje rovněž požadavek uživatelského klienta zpoza předřazeného registru) – zelené šipky.
Information request from the legacy register to its core system (this route also includes a request from a custom client behind the legacy register) — green arrows.
Tento druh žádosti je tvořen druhy zpráv 5 a 10.
This kind of request consists of message types 5 and 10,
Obrázek: Druhy zpráv pro zaznamenání
Figure: Message types for logging
Hardwarový bezpečnostní modul
Hardware Security Module
Hardwarový bezpečnostní modul se nepoužívá.
A Hardware Security Module is not used.
Hardwarový bezpečnostní modul (HSM) zajišťuje vhodnou ochranu pro klíč používaný k označení zpráv a k určení serverů.
A Hardware Security Module (HSM) provides good protection for the key used to sign messages and to identify servers.