CEN/TC 331/WG 3 - Automatic identification of items - Addresses

This document covers physical properties and manufacturing requirements for envelopes having an address window and the flap on the front side once the flap has been sealed, hereafter the flap side. It covers the main design features of the reverse envelope, notably of the flap and address window, and the materials used for the manufacturing thereof. It applies to reverse envelopes with advertising or communication printed on the plain side, eventually on its entire surface.
This document covers empty envelopes, but also finished mailpieces that have been properly inserted, addressed and franked (reverse mailpieces) and are submitted to Postal Operators. In particular, reverse mailpieces will be compliant with relevant Postal standards applicable in the member states.
By extension, these requirements also apply to non-window envelopes used for reverse mailpieces and having the address printed on the flap side.
This document does not apply to:
-   envelopes with a large window on the plain side (opposite to the flap) as these are already common and widely accepted,
-   paper requirements to ensure print quality (except for the postage mark and address) and notably colour rendering.

The scope of this document is the forward flow of E-Commerce items. Starting point is arrival at a lo-gistic service provider, end point is the final delivery, or at least the attempt to final delivery.
The returns flows, either caused by unsuccessful delivery, "return to sender" or as a service for recipi-ents to send a received shipment back, are not covered by the forward events. To keep this document unambiguous and easy to understand, these return flows are excluded. Return flows may be covered in a separate technical specification.
Not in scope are the logistical flows within the facilities of the producers and sellers of the items. These fall outside the responsibility of the CEN/TC 331 domain.
Excluded as well, are all events necessary for an LSP to track items within its own facilities. It is up to the LSP how to run its business, and internal standards are in place for the management of internal process-es. Internal events are considered to be of no interest to a recipient, with the exception of some of the last mile events which are mentioned later in this document.

This document specifies new methods available to customers from the logistic transportation companies for safe secure and contactless delivery of postal items.
The methods specified in this document provides the senders and the receivers with a proof of receipt or proof that an attempt of delivery was made. It includes methods on how to deliver without having the customer to sign for the delivery.
More specifically, the methods specified in this document cover the process of last mile delivery of postal items, including home delivery and delivery at public places, residential buildings and corporate buildings.
This document describes all delivery methods, including those requiring physical contact, and rank them from a health and safety, and operational point of view.

This document establishes a common methodology for the calculation, allocation and declaration of Greenhouse gases (GHGs) as well as air pollutant emissions related to any parcel delivery service.
It only covers a part of the entire retail value chain. The retail value chain usually consists of creating the product, storing the inventory, distributing the goods and making the product available for consumers.
This document includes only the distribution of goods but considers the entire value chain of the parcel transportation process flow, namely the collection and delivery rounds, the trunking and the operations due to processing and the physical handling of parcels. See Figure 1 below for a graphical illustration.

This document:
- specifies a methodology for the measurement of defined print quality attributes of Digital Postage Marks in the form of two-dimensional bar code symbols on mail-pieces;
- defines methods for grading the results of these measurements and deriving an overall symbol quality grade as a guide to estimating the readability of the Digital Postage Marks;
- provides guidelines for printing and gives information on possible causes of deviation from high grades to assist users in taking appropriate corrective action;
- defines a test procedure for the assessment of printing systems for the production of Digital Postage Marks.
These provisions apply to the Digital Postage Mark blocks as they appear on fully produced mail items when remitted to postal operators, including the characteristics resulting from operations other than printing per se that affect their appearance to a mail processing system (covering, inserts into transparent window envelopes, affixed Digital Postage Mark labels).
This document does not define the qualification tests or sampling requirements necessary to determine the practical feasibility of any specific read rate.
Although this document is not intended for barcodes (other than Digital Postal Marks) which can be printed on mail pieces for item identification or additional services, a similar methodology can be applied.

This document covers physical properties and characteristics for the packaging for small and light weight postal items to be delivered into the consumer’s letterbox. It covers the main design features for the packaging of letterboxable postal items, notably the sizes and stacking as well as postal and environmental requirements.
This document is targeted to e-retailers and postal operators.

2020-07-08 - TC - Correction of two formats in rows "Item identifier" and "Additional barcode" in Table 1

This document specifies the information exchanges between various parties' infrastructures that take place in support of DPM applications. It complements standards that address the design, security, applications and readability of Digital Postage Marks.
The following items will be addressed by this document:
-   identification of parties participating in exchanges of information described by this document;
-   identification of functions (interactions, use cases);
-   definition of parties’ responsibilities in the context of above functions;
-   definition of messages between parties: message meaning and definition of communication protocols to support each function;
-   definition of significant content (payload) for each message;
-   security mechanisms providing required security services, such as authentication, privacy, integrity and non-repudiation.
This document does not address:
-   design of DPM supporting infrastructure for applications internal to providers and carriers;
-   design of DPM devices and applications for applications internal to end-users.
NOTE   Although there are other communications between various parties involved in postal communications, this document covers only DPM-related aspects of such communications.

This document will specify the interface between the e-merchant (any commercial customer sending parcels) and the first logistic operator, including both public and private carriers. For the application of this document, a cross border parcel is a parcel crossing a border into and within Europe.
The interface composed on two items:
- the physical label attached on the parcel: contents, sizes, minimum requirements to guarantee the quality and efficiency of the logistic process (sorting, delivery).
- the electronic exchanges between the sender and the logistic operator with the description of the data to be provided, the forma of the exchanges.
While designated operators of UPU have drawn up business requirements using proprietary standards and related data components, online merchants have developed open, not‐for‐profit standards for final delivery which are integrated into their existing supply chain management environment.
The document aims to specify the interface between the e‐merchant (any commercial customer sending parcels) and the first logistic operator composed by incorporating the 3 elements:
- physical label attached to the parcel with information for item identification;
- electronic exchanges between the sender and the logistic operator concerning parcels dispatch;
- data needed for various delivery chain parts, in particular final delivery to the recipient, in order to facilitate exchange between the item‐specific identifiers.
NOTE 1 The last element enables the growth of integrated, data‐driven systems which support highly efficient and customer‐driven cross‐border ecommerce. This reflects the current trend to B‐to‐B‐to‐C delivery solutions in the European and international cross border e‐commerce markets. Delivery from original source to final consumer can be split over more than one service provider.
NOTE 2 C‐to‐B‐to‐B‐to‐C solutions will be an extension, in particular when returns are specified. The “first C” would indicate that consumers wishing to return items, or induct items themselves, will be able to print labels following the fundamentals specified in this standard.
E‐merchant exchange data with logistic operators (i.e. the postal operators, but not limited to those designated to fulfil the rights and obligations of UPU member countries) to help, simplify and enable the consequential logistic and transactional tasks. The establishment of common definitions and electronic formats, safeguards the reliability and decreases the overall costs by avoiding software development costs, multiple printing equipment, over‐labelling during the process, and the manual sorting. reliability and decreases the overall costs by avoiding software development costs, multiple printing equipment, over‐labelling during the process, and the manual sorting.

This European Standard specifies a recommended procedure for the development of specifications for applications of digital postage marks (DPMs) – i.e. applications linked to the use of digital printing and image data capture technologies in the postal industry, most particularly for the evidencing of postage accounting and/or payment. It is not intended to prescribe or to recommend any particular architecture or design for such applications, only to specify the process through which such an architecture or design should be developed.
The document covers only requirements and considerations relating to applications that use digital postage marks, on individual postal items, as a means of communicating data (messages). The clause on design covers only the design of the digital postage marks themselves. It does not cover other aspects of design, including the possible use of other messages, transported by other means (e.g. statements of mailing), to provide for the communication of additional data, even though these might be just as important.

An IDT-PAE interface enables interoperability among several systems and processes by providing specifications to the following requirements:
a)   Data Collection and Transfer:  Specification of data transported from the devices to higher level systems.  There may be more than one permissible protocol referring to different OSI layers. The standard will define where the communication requires polling and where asynchronous messages are used.
   The basis is messages triggered by events.
b)   Data Storage and Format:  Specification how data is formatted and structured. This concerns the choice between XML, CSV, EDI, JSON and other formats including possible binary representations.
c)   Data Model:  Specification of the semantics (meanings) behind the data. This is the most important part and the one of the most important objectives for the specification. This means that conceptual data model and its mapping to the Data Format will be developed. Major focus on specifications level of detail will be placed in order to provide a document that will provide detailed specification information without being too general or too specific.

This Technical Specification defines a uniform structure and meaning for the information that fully represents postal rates for a broad variety of postal products in all mail categories. The postal rates definition is viewed as an important interface between posts and their customers and as such will benefit from standardization. Such representation of postal rates allows automated systems to uniformly use postal rates as they are introduced for new products or updated for existing postal products by postal operators. A postal rate file (PRF) is an XML document, which fully describes postal products rates. It contains all necessary and sufficient information for both postal operators and their customers to efficiently create, respectively acquire, update and process postal product rates. The structure, types and constraints of XML elements in an XML document are defined by an XML schema. The Extensible Postal Rates (EPR) schema is the XML schema that governs Postal Rate Files.
This Technical Specification contains a complete description of the EPR schema, its hierarchical structure, information types and semantics of its elements.
This Technical Specification neither defines nor constraints how postal rates are created by postal operators but rather provide a powerful and flexible tool that supports efficient rates definition, management and distribution.
This Technical Specification does not define communication protocols that can be used by posts to distribute postal rates files to their customers. Suitable communication protocols are typically well known and already standardized (for example: Web Services, File Transport Protocol, email, etc.). The standard also does not define valuation of postal products as applied by postal operators and their customers.

The purpose of this Technical Specification is to define the requirements of the OCR/VCS Standard interface and to convey these requirements in context to the reader.
This document is arranged under 4 main clauses as described in Figure 1:
-   UCM (Use Case Model) describes the use cases for the IC/ED Interface using sequence diagrams with messages.
-   IDD (Interface Design Description) defines the data model for the IC/ED interface.
-   SDD (System Design Description) defines the mandatory specification of the IC/ED interface in terms of architecture, services and behavioural models. In the Common Part of this clause no middleware or transport layer is specified. The common part of this clause is intended to be middleware-independent.
-   SDD-TCP/IP, SDD-CORBA, in these specialized clauses. The specifications for 2 compatible transport solutions TCP/IP, CORBA are provided. Further middleware solutions (such as SOAP) can be added when available, provided that they are fully compatible with the Common Part.
As shown on Figure 2, there are many interfaces from an Enrichment Device to the rest of the system. This document is only concerned with the Mailpiece Processing part of the complete Standard Interface.
The mailpiece processing is concerned with the passing of a mailpiece to an Enrichment Device for processing.
Figure 3 depicts the system model of an Enrichment Device. As visible on the figure, an Enrichment Device is one of:
-   an OCR:
a single or a pool of automatic recognition and interpretation engines, which are capable of retrieving information from an image of a mailpiece without human intervention;
-   a VCS:
a single or a pool of video coding desks, which produce results from images of mailpieces; all tasks related to the management of the coders and the coding desks are encapsulated within the VCS system, or are accessible via interfaces which are outside the scope of the interface described within this document;
-   a Voter:
a system which can determine the most appropriate result for a mailpiece using data and/or an image of a mailpiece; typically, a voter determines the most appropriate result from two or more results.
This document therefore covers the Mailpiece Processing interface between the Image Controller and the Enrichment Devices.
The document describes the requirements in the case of real-time enrichment: operational mode of an Enrichment Device, where the ED replies within the specified expiration time to the IC; the IC has to keep track of all mailpieces waiting for a reply from an ED. The ED does not keep persistence of mailpieces outside a channel connection with the IC. The ED has to have the processing power available to enrich a mailpiece. There is one and only one response for a mailpiece.
A later version of the document shall describe the case of deferred enrichment: operational mode of an Enrichment Device, where the ED may pre-request mailpieces from the IC. The ED has to keep persistence of the mailpiece to enrich it later and keep the result available for a result request from the IC. There is no response expected by IC from the ED.
The interface between Image Controller and Image Controller is NOT part of this document.
Furthermore, there may be many IC connected to many ED’s, as shown in the following object model:
The submission strategy in case of one IC connected to many ED’s is not part of the interface. It is for optimizing the mail flow in case of identical ED’s, or for defining the order in which different ED’s are activated (cascaded versus parallel submission).
The submission strategy of the IC shall be part of the specification and certification of the IC, which is not part of this document.

This Technical Specification specifies the sort plan file content and structure. It does not deal with other configuration files in sorting machines nor is it applicable to the transport mechanism.
The content of a sort plan allows the specification of the following capabilities:  
-   sorting by address and non-address attributes;
-   sorting of code ranges;
-   sorting of rejects;
-   support of display and label texts;
-   dynamic outlet groups;
-   sorting to more than one outlet;
-   overflow handling;
-   support of cut off time before dispatch;
-   sequence sorting;
-   provide volume information (option);
-   support of Cards;
-   possibility to add simple manufacturer specific information;
-   support of various sort code formats and non-address attributes;
-   support of various display and label formats;
-   check against characteristics of the sorting machine.

This Technical Specification describes the “Open Standard Interface between Image Processor, Machine Control and Image Controller” (IP/MC/IC Interface) in the context of postal automation equipment.
The following architectural overview is the basis for this interface standardization:
It was agreed to unify the interfaces between
a) Image Processor and Image Controller,
b) Image Processor and Machine Control and
c) Machine Control and Image Controller
and to produce one common specification for this so-called IP/MC/IC Interface.
The communication partners of this interface will be called Machine or Machine Control (MC) on the one side and Reading/Coding (RC) System on the other side.
There may be several instances of this interface, depending on the implementation of the MC and the connected RC.
NOTE   interfaces for synchronizing the lifted images with their mailpiece_IDs provided by the machine are not shown in the figure above and are not subject of standardization within the first release of this interface.
From the customer point of view the following two scenarios are relevant. The systems MACHINE and RC SYSTEM are to be considered as "black boxes" thus not detailing internal system structure and interfaces.
1) The Machine already includes Camera and Image Processor and will be connected to a 3rd-party RC System including Image Controller and Enrichment Devices.
2) The Machine will be connected to a 3rd-party RC System including Camera, Image Processor, Image Controller and Enrichment Devices. The Camera and (possibly) the Image Processor will have to be mechanically integrated into the machine.
NOTE   The camera can be provided by any 3rd-party. This should not impede on the IP/MC/IC interfaces !
This standard is arranged under 4 main clauses as described in Figure 4.
- UCM (Use Case Model) describes the use cases for the IP/MC/IC Interface using sequence diagrams with messages.
- IDD (Interface Design Description) defines the data model (...)

This part of the Technical Specification defines the representation of ID-tags as a Postal-4i symbology 4-state bar code printed on the front side of flats. Many of the provisions are applicable also to small letters and are therefore referenced by Part 5 of the specification (CEN/TS 15844-5), which covers these.
Postal-4i symbology 4-state encoding is the only encoding specification supported by this Technical Specification  ) for the printing of ID-tags on the front of items.
NOTE   Representation in the form of fluorescent BNB bar codes printed on the reverse side of small letters (not flats) is covered in CEN/TS 15844-2 and CEN/TS 15844-3.

This part of the Technical Specification defines the representation of ID-tags as a 78-position bar-no-bar code (BNB-78) printed in fluorescent ink in area R1 on the reverse side of items.
BNB-78 encoding is one of two encoding specifications supported by this Technical Specification  ) for the printing of ID-tags in area R1, the other being BNB-62, which is specified in CEN/TS 15844-3.
NOTE 1   Representation in the form of a 4-state code printed on the front of the item is covered in CEN/TS 15844-4 for flats and CEN/TS 15844-5 for small letters.
BNB-78 encoding supersedes the earlier specified BNB-62 encoding and shall be applied in all cases in which ID-tags are placed in area R1 on the reverse side of letter mail items of size up to and including C5, by issuers other than those explicitly authorised to continue use of BNB-62 encoding, namely An Post (Ireland), Canada Post and United States Postal Service.
NOTE 2   ID-tags encoded in area R1 are required by article RL 123 of the UPU Letter Post Regulations [1] to be compliant with UPU standard S18 – and by this with the related CEN/TS 15844. This supports only two encodings in area R1, namely BNB-78 as defined herein and BNB-62 as defined in CEN/TS 15844-3. The latter is authorised for continued use only by the three issuers mentioned above. Where ID-tags are used, and are applied in area R1 on the reverse side of letter mail items of size up to and including C5, the use of BNB-78 encoding is mandatory for all other issuers.
NOTE 3   BNB-78 encoding is not considered suitable for use on flats. CEN/TS 15844-4 defines a 4-state encoding which may be used for this purpose.

This part of the Technical Specification defines the representation of ID-tags as a Postal-4i symbology 4-state bar code printed on the front side of small letters.
Postal-4i symbology 4-state encoding is the only encoding specification supported by this Technical Specification  ) for the printing of ID-tags on the front of items.
NOTE   Representation in the form of fluorescent BNB bar codes printed on the reverse side of small letters (not flats) is covered in CEN/TS 15844-2 and CEN/TS 15844-3.

This part of the Technical Specification defines the representation of ID-tags as a 62-position bar-no-bar code (BNB-62) printed in fluorescent ink in area R1 on the reverse side of items.
BNB-62 encoding is one of two encoding specifications supported by this Technical Specification  ) for the printing of ID-tags in area R1, the other being BNB-78, which is specified in CEN/TS 15844-2.
NOTE 1   Representation in the form of a 4-state code printed on the front of the item is covered in CEN/TS 15844-4 for flats and CEN/TS 15844-5 for small letters.
BNB-62 encoding is authorised for use only by three issuers: An Post (Ireland), Canada Post and USPS. It should be encountered, on incoming items, only on mail items which originated in Canada, Ireland or the United States. Other issuers wishing to apply ID-tags in area R1 are required to use the BNB-78 encoding defined in CEN/TS 15844-2.
NOTE 2   ID-tags encoded in area R1 are required by article RL 123 of the UPU Letter Post Regulations [2] to be compliant with UPU standard S18 - and by this with the related CEN/TS 15844. This supports only two encodings in area R1, namely BNB-78 as defined in CEN/TS 15844-2 and BNB-62 as defined herein. The latter is authorised for continued use only by the three issuers mentioned above. Where ID-tags are used, and are applied in area R1 on the reverse side of letter mail items of size up to and including C5, the use of BNB-78 encoding is mandatory for all other issuers.
NOTE 3   BNB-62 encoding is not considered suitable for use on flats. CEN/TS 15844-4 defines a 4-state encoding which may be used for this purpose.

This Technical Specification  ) defines the information content, structure and possible printed representations of the S18 ID-tag  ). This is an identifier for individual mail items which:
   is globally unique;
   can be applied to any item which is not already ID-tagged by any postal administration (or other issuer) which previously processed the item;
NOTE 1   The S18 ID-tag provides a standard means of ID-tagging which can be applied on a world-wide basis, allowing inter-administration mail items to be encoded without risk of disruption of the automated system of the delivery post. It may be applied to any size of item.
   can be read, with a high degree of reliability, by any postal handling organisation possessing appropriate equipment.
NOTE 2   ID-tags are encoded on items using a bar code symbology. As with any other form of bar code, poor quality printing, ink smudging, damage to the item, etc., can result in read errors. The S18 ID-tag encoding specifications incorporate an error protection mechanism to allow detection and correction of a large proportion of such errors.
The S18 ID-tag defined in this Technical Specification may be placed on items so that, in subsequent processing, individual items can be recognised and associated with computer-based information relating to the item concerned.
NOTE 3   Items need not be ID-tagged if this is not required for processing purposes, though it is anticipated that the use made of ID-tagging will increase. Examples of ID-tag applications are given in Clause 7.
Whilst being generally applicable to domestic mail, the specification has been designed to allow the encoding of cross-border mail and to support its application in the automated processing of such mail.
NOTE 4   UPU regulations prevent the encoding of information on the bottom 15 mm strip on the front of international letter mail. (...)

This document defines a file format for the generation of postal address directories. It is designed to hold all information necessary to support address reading software including data required for forwarding applications. In typical postal automation systems these files will be processed by directory generation software which creates application specific loadable data. This data – usually referred to as operational directory – is heavily compressed and contains access tables tailored for the specific reading software.
Not in the scope of this document are topics external to file like compression, checksums, the interface for transmission to the supplier, modification permissions, error handling on inconsistent data and undo in updates.

This Technical Specification defines a set of physical marks called Address Block Locators (ABLs). ABLs are marks, printed in the vicinity of addresses on postal items, that are intended to facilitate automatic recognition of address location and processing of the addresses on mail sorting and video-coding equipment.
The Technical Specification describes two families of ABLs which may be printed on all types of postal items, including letters, flats and parcels.
In the first family, address block locators take the form of pictograms which bear no other information than being a landmark for the address block. One such pictogram is defined herein for use in association with the delivery address block. It may be printed at the same time as the address or pre-printed on an envelope, an insert, or a label, with the address being printed, on the same physical support, at a later stage.
The second family covers address block locators which contain an encoded specification of the address block type and location and which can also be used for encoding other data, not directly related to address block location. Such data may include addressee or postal item identifiers, routing data, non-delivery instructions, a return address and references or other data which are relevant for either the mailer or the addressee. It may also include address checking data which may be used to verify correct interpretation of the printed address by the OCR system. In this family, three types of ABL are defined: one based on a pattern of alphanumeric characters; one on a linear bar code and one based on two-dimensional symbologies. These locators can be applied to the delivery address block and to forwarding or return address blocks. They will normally be printed within the same process as the address itself.
The Technical Specification is intended to be used by:
-   mailers, during the production of mail;
(....)

The purpose of this Technical Specification is to define a facing identification mark (FIM), with procedures for its use, which can be used by any postal operator. It is primarily addressed to those postal operators that have not yet implemented the use of FIMs for automated facing and has been designed to minimise conflict with FIM marks that are already in use. Nevertheless, operators with existing FIMs are encouraged to consider support for migration onto this Technical Specification as and when they upgrade or replace facing equipment.
Use of the standard FIM offers the possibility for automated preparation of letters which do not carry a stamp and which arrive, in a postal facility, without being faced. These items can them be included in the domestic and international mechanised streams of mail.
This Technical Specification allows facer-cancellers and culler-facer-cancellers (or other automated equipment supporting the mail preparation function), to detect bar code-type marks enabling those machines to face and cancel items carrying the FIM. Through the incorporation of a coded value, called the FIM-code, this Technical Specification also supports segregation of FIM-marked items into up to 18 separate streams. This capability can be used to facilitate revenue control by allowing items to be segregated according the type of revenue control procedure required. For example, Business Reply items could be separated and allow accounting and cancellation to take place before, rather than after, the items are transported to their delivery office. This would simplify controls designed to prevent the sending of business reply items to addresses in other countries. However, it should be recognized that FIMs have no in-built security and an item may carry an inappropriate FIM code, resulting in it being placed in the wrong processing stream. Hence, in particular, the FIM alone cannot be relied upon as providing evidence of payment.

This document provides guidelines for printing addresses on mail items. These guidelines apply to addresses printed on mail items whose size is up to and including C5. It may also be applied to oversize items, commonly referred to as C5+. The address blocks covered are the addressee address block and the sender address block if they are both on the same side of the item. Otherwise, only the addressee address block is covered. Guidelines related to address lines are relevant for all lines in an address block.

This document covers physical properties and manufacturing requirements for envelopes having an address window on the flap side. It covers the main design features of the reverse envelope, notably of the flap and address window, and the materials used for the manufacturing thereof. It applies to reverse envelopes with advertising or communication printed on the plain side, eventually on its entire surface.
This document covers empty envelopes, but also finished mailpieces that have been properly inserted, addressed and franked (reversed mailpieces) and are submitted to Postal Operators. In particular, reverse mailpieces will be compliant with relevant Postal standards applicable in the member states.
By extension, these requirements also apply to non-window envelopes used for reverse mailpieces and having the address printed on the flap side.
This document does not apply to:
-   envelopes with a large window on the plain side (opposite to the flap) as these are already common and widely accepted;
-   paper requirements to ensure print quality (except for the postage mark and address) and notably colour rendering.

ISO 19160-4:2017 defines key terms for postal addressing, postal address components and constraints on their use.
Specifically, ISO 19160-4:2017 defines postal address components organized into three hierarchical levels:
-      elements, such as organization name or postcode, which have well-defined conceptual meaning and are not themselves made up of subordinate components, though they may be sub-divided for technical purposes;
-      constructs, such as organization identification, which group elements into units form a logical portion of a postal address;
-      segments, such as addressee specification, which group-related postal address constructs and/or postal address elements into units with a specific defined function.
ISO 19160-4:2017 also specifies a mechanism for creation of sub-elements, which correspond to either sub-divisions of element content, such as door type or door indicator or to multiple occurrences and locations of elements in an address, such as levels of administrative regions.
ISO 19160-4:2017 does not specify the length of any component nor the value range of any component.
Moreover, ISO 19160-4:2017 defines the codes to identify elements and sub-elements.
Further, ISO 19160-4:2017 specifies postal address rendering rules. This includes identification and ordering of output lines in a rendered address, conditions for selection of candidate lines, the order and concatenation of postal address components, required and optional components, parameters to contextualize address for rendering and the formatting of the components, subject to constraints on the space available for that task. Postal address rendering rules are represented in ISO 19160-4:2017 as a postal address template.
Finally, ISO 19160-4:2017 specifies language suitable for computer processing to formally express postal address templates.

This document specifies the information exchanges between various parties' infrastructures that take place in support of DPM applications. It complements standards that address the design, security, applications and readability of Digital Postage Marks.
The following items will be addressed by this document:
-   identification of parties participating in exchanges of information described by this document;
-   identification of functions (interactions, use cases);
-   definition of parties’ responsibilities in the context of above functions;
-   definition of messages between parties: message meaning and definition of communication protocols to support each function;
-   definition of significant content (payload) for each message;
-   security mechanisms providing required security services, such as authentication, privacy, integrity and non-repudiation.
This document does not address:
-   design of DPM supporting infrastructure for applications internal to providers and carriers;
-   design of DPM devices and applications for applications internal to end-users.
NOTE   Although there are other communications between various parties involved in postal communications, this document covers only DPM-related aspects of such communications.

This Technical Specification will specify the interface between the e-merchant (any commercial customer sending parcels) and the first logistic operator.
The interface is composed on two items:
-   the physical label stuck on the postal item: contents, sizes, minimum requirements to guarantee the quality and efficiency of the logistic process (sorting, delivery).
-   the electronic exchanges between the sender and the logistic operator with the description of the data to be provided, the format of the exchanges.
While designated operators of UPU have drawn up business requirements using proprietary standards and related data components, online merchants have developed open, not-for-profit standards for final delivery which are integrated into their existing supply chain management environment.
The Technical Specification aims to specify the interface between the e-merchant (any commercial customer sending postal items) and the first logistic operator composed by incorporating the 3 elements:
-   physical label attached to the postal item with information for item identification;
-   electronic exchanges between the sender and the logistic operator concerning parcels dispatch;
-   data needed for various delivery chain parts, in particular final delivery to the recipient, in order to facilitate exchange between the item-specific identifiers.
NOTE 1   The last element enables the growth of integrated, data-driven systems which support highly efficient and customer-driven cross-border ecommerce. This reflects the current trend to B-to-B-to-C delivery solutions in the European and international cross border e-commerce markets. Delivery from original source to final consumer can be split over more than one service provider.
NOTE 2   C-to-B-to-B-to-C solutions will be an extension, in particular when returns are specified. The “first C” would indicate that consumers wishing to return items, or induct items themselves, will be able to print labels following the fundamentals specified in this standard.
E-merchant exchange data with logistic operators (i.e. the postal operators, but not limited to those designated to fulfill the rights and obligations of UPU member countries) to help, simplify and enable the consequential logistic and transactional tasks. The establishment of common definitions and electronic formats, safeguards the reliability and decreases the overall costs by avoiding software development costs, multiple printing equipment, over-labelling during the process, and the manual sorting.

This document specifies a recommended procedure for the development of specifications for applications of digital postage marks (DPMs)- i.e. applications linked to the use of digital printing and image data capture technologies in the postal industry, most particularly for the evidencing of postage accounting and/or payment. It is not intended to prescribe or to recommend any particular architecture or design for such applications, only to specify the process through which such an architecture or design should be developed.
NOTE 1   For this reason, the standard includes both normative and informative content. Clauses 1 to 5 and Annex A are normative, whilst the remaining annexes are informative. Non-normative (informative) clauses are indicated as such in the heading.
The process described is based on a cyclic model, involving business planning; systems analysis; security analysis and detailed DPM design.
The defined process is a recommended one only and DPM applications designers are not obligated to follow it. However, its use is intended to ensure both that all relevant aspects are taken into account in the design process and that the resulting specifications have a degree of commonality of structure which make them comparable with similar specifications produced by other parties. It is hoped that this will make them more easily intelligible, and less open to ambiguity, for implementers.
It is assumed that users of the standard are familiar with normal processes involved in the design of computer-based applications and the standard therefore limits itself to aspects which are specific to DPM applications design. In particular, the document covers only requirements and considerations relating to applications that use digital postage marks, on individual postal items, as a means of communicating data (messages). The clause on design covers only the design of the digital postage marks themselves. It does not cover other aspects of design, including the possible u

This part of the standard describes the address templates for each country, i.e. the specific way an address is formatted in each country, indicating in particular the order in which the various elements appear. The address templates may include rendition instructions, specifying how elements are to be rendered for printing.
EN14142-1:2011 contains material that is not country-specific and is expected to remain stable for a significant period of time. CEN/TR14142-2:2011 contains the country specific information as well as explaining mapping conventions and design considerations that are generic in scope but are still evolving and have a current status rather than a fixed resolution.
What then are the characteristics of the generic material in Part 2? As an example, the definition of (40.17 district) as a postal address element is stable and not country-specific, for example, and thus the definition is assigned to Part 1. At the same time, some of the uses of (40.17 district) to represent different levels and positions, while occurring in one or more specific country templates, reflect generic element mapping conventions and generic template design considerations. These generic conventions and considerations are explained in Part 2, along with generic rendition instructions used in country templates, together with the country templates, country-specific rendition instructions, and presentation rules defined by each country.
It is expected that Part 2 shall be modified from time to time to add new countries, modify country templates, and as appropriate, to elaborate upon the element mapping conventions and template design considerations and to amplify the roster of generic rendition instructions. Notwithstanding the potential for modifications, the stable content of Part 1, taken together with the current understanding of these generic conventions and parameters, including the NLT and PATDL templates for those countries represented, is intended when taken together to comprise a consistent international standard.

This document specifies the electrical, data and timing interface between the control unit of a postal sorting system and an ink jet printer connected to that system. It further specifies an ancillary interface to the printer, which can be used for the support of remote diagnostics and other service functions.
NOTE 1   This specification can equally be applied to the interfacing of printers to sequencing systems and combined sorting and sequencing systems.  It was primarily developed for application to ink jet printers, but could be applied to printers with similar functionality that make use of other printing technologies.
At the physical level, the specification is based on the use of a combination of a standard 100 Mbps Ethernet connection for the transfer of data and patch cables for signalling. At a logical level, data is transferred using messages transmitted across the Ethernet connection using three TCP/IP sockets, with the execution of time-critical functions being controlled through the use of signals on a TIA/EIA-422 interface.
NOTE 2   Several printers can be connected to a single sorting system. In this case, the printers can optionally share access to a single Ethernet network, but each requires its own patch cables.  This standard does not support the connection of a single printer to multiple sorting system control units.
This document defines all messages that may be transferred via each of the TCP/IP sockets, specifies printer behaviour on receipt of these messages and defines how the timing of this behaviour is controlled by the TIA/EIA-422 signals......

TC - B.6.3.4.3.5, 2nd paragraph - Correction of reference

The purpose of this document is to define the requirements of the OCR/VCS Standard interface and to convey these requirements in context to the reader.
The interface specification is contained in the two appendices of this document, both of them normative:
·   System Design Description (SDD)
This document specifies the class model, dynamic behaviour and exception handling of the interface. The API is included.
·   Interface Design Document (IDD)
The IDD in Annex B defines the "payload" information for the interface. That is the data which is required for processing a mailpiece e.g.
Figure 1 - Interface environment of an Enrichment Device
As shown on Figure 1, there are many interfaces from an Enrichment Device to the rest of the system. This document is only concerned with the Mailpiece Processing part of the complete Standard Interface.
The mailpiece processing is concerned with the passing of a mailpiece to an Enrichment Device for processing.

This document specifies a methodology that allows postal operators to define specific statements of mailing submission customised according to their environment and applications.
The document defines information requirements for existing generic postal information processing applications related to major postal functions, namely operations, finance and marketing by specifically identifying the information that could be collected within the mailer’s domain and transmitted to the postal domain.
In addition, this document defines the organisation of data into messages by describing data content, format and communication protocol suitable for communication of data originating in the mailer’s domain.
The specification also provides a detailed analysis and recommendations for implementing application level security threats and countermeasures particularly relevant for postal revenue protection in controlled mail entry settings.
Finally, this document provides several examples of concrete statements of mailing submissions and an example of a secure communication protocol recommended for transmission of such statements.
NOTE   The SMS describes letter mail or flats that are submitted for distribution and would not deal explicitly with content of letters or flats whether it concerns customs or any other party that could in principle be interested in knowing the content of these mail entities.

The standard will define the components of the address and their formats and guidelines on how to indicate the address on a letter post item. The standard will also define data elements for postal addresses, specify data fields and define rules for the representation of address information in files and on envelopes including number of lines and characters per line.

This document:
- specifies a methodology for the measurement of defined print quality attributes of Digital Postage Marks in the form of two-dimensional bar code symbols on mail-pieces,
- defines methods for grading the results of these measurements and deriving an overall symbol quality grade as a guide to estimating the readability of the Digital Postage Marks,
- provides guidelines for printing and gives information on possible causes of deviation from high grades to assist users in taking appropriate corrective action,
- defines a test procedure for the assessment of printing systems for the production of Digital Postage Marks.
These provisions apply to the Digital Postage Mark blocks as they appear on fully produced mail items when remitted to postal operators, including the characteristics resulting from operations other than printing per se that affect their appearance to a mail processing system (covering, inserts into transparent window envelopes, affixed Digital Postage Mark labels).
This document does not define the qualification tests or sampling requirements necessary to determine the practical feasibility of any specific read rate.