CEN/TC 331/WG 2 - Hybrid mail

The scope will be defined during the preliminary stage.

The scope will be defined during the preliminary stage.

The purpose of this Technical Specification is to define the syntax rules for a data stream for the submission of printing data to a Hybrid Mail operator or between Hybrid Mail operators. The Technical Specification defines a XML Schema Definition (XSD) describing the data stream.
The description is based upon the XML (eXtended Mark-up Language) definition of rules and semantics for defining an XSD. The purpose of this is to offer a generalised syntax description that can provide seamless integration with a number of existing applications generating data that is liable to be forwarded to or from a Hybrid Mail operator.
The use of an XSD will ensure that the documents confirm to the standard defined and that the output has the correct syntax. Software manufacturers can use an XSD to program applications that will produce correct outputs.
This Technical Specification defines the syntax for creating a data stream that will eventually be converted into a deliverable. The overall object (a batch) can be divided into one or more objects that again can be divided into objects. The hierarchy includes bundles that contain a common part and letters. Each object has a number of characteristics attached to it.
This diagram shows the structure of a HML (Hybrid Mail Language) document: each letter is self-contained (contains all the necessary information to be delivered on a certain destination).
Each letter can have one contact. Each contact can have multiple alternatives for delivery.
This Technical Specification does not define the specific services offered by local operators (Hybrid Mail operators).
This Technical Specification does not define the communication method used. It does only define the format of Hybrid Mail as such.

This Technical Specification constitutes the functional specification of a secure electronic postal service, referred to as the postal registered electronic mail or PReM service. PReM provides a trusted and certified electronic mail exchange between mailer, postal operators and addressee/mailee. In addition, evidence of corresponding events and operations within the scope of PReM will be generated and archived for future attestation.
The PReM service is defined by reference to the concepts, schemas and operations defined in CEN/TS 15121-1:2011. It utilises six SePS operational verbs (CheckIntegrity, LogEvent, Postmark, RetrieveResults, Sign and Verify) and the five additional server-side operational verbs (SendMessagetoDestination, Subscribe Notification, UnscbscribeNotification, RejectMessage and ReceiveNotification) to fulfil the operational requirements of a PReM System.
Return of Investment (ROI), market potential, revenues model, business plan and pricing policy are outside the scope of this functional specification. Postal operators are advised to make the necessary marketing study and research prior to considering leasing, procuring or developing such a PReM system in accordance with this functional specification.

This document specifies a secured electronic postal service, referred to as the Electronic Postal Certification Mark (EPCM) service, which provides a chain of evidence, stored by an administration as a trusted third party, to prove the existence of an electronic event, for a certain content, at a certain date and time, and involving one or more identified parties.
The service is defined by reference to the concepts, schemas and operations defined in
CEN/TS 15121-1, Postal Services - Hybrid Mail - Part 1: Secured electronic postal services (SePS) interface specification - Concepts, schemas and operations. It requires support for five core SePS operations and permits optional support seven others.
This version of the specification does not cover:
-   a description of the issues surrounding inter-operability between multiple postal SePS implementations when a business transaction Lifecycle requires the participation of more than one SePS implementation in a cross-border scenario involving two or more postal services;
-   issues surrounding SePS usage in a ‘multiple Certificate Authority’ scenario where inter-operating posts are participating in a cross-border transaction as described above;
-   examination of "Certificate Authority deployment model" alternatives necessitated by the cross-border scenarios described above.

This document specifies a standard XML interface that will enable software applications to call a secured electronic postal service (SePS), provided by a postal service, which is based on the concepts, schemas and operations described herein.
The specification provides:
-   a definition of standard operations which can be combined to support secured electronic postal services;
-   a full description of all mandatory and optional request parameters required for use of these operations;
-   a full description of all response elements and the detailed circumstances under which they are returned.
The specification also describes the functionality and edit rules of the actual technical specification artifacts, which are represented by an XML Schema (XSD) and an associated Web Services Definition Language (WSDL) specification. The versions of these applicable at the date of publication of this version of the specification are contained in this document as Annex A and Annex B respectively. These can also be obtained in electronic format from the UPU Technical Standards CD-ROM or from the UPU Standards Secretariat.
In case of any conflict between Annex A and other provisions of this specification, Annex A shall be regarded as definitive.
The SePS schema specification in Annex A is discreet and version specific. Postal Services are free to select which discrete interface versions they support. However, except in the case of upgrades to V1.15 adopted to ensure cross-border compatibility, postal services who upgrade from older versions of the schema (e.g. from V1.14) to a newer one are required to support backward compatibility of previously supported versions of the SePS interface specification as it applies to both processing requests/responses and honoring previously issued PostMarkedReceipts. Individual posts are free to address this backward compatibility challenge as they see fit.
(....)

The purpose of this Technical Specification is to define the syntax rules for a data stream for the submission of printing data to a Hybrid Mail operator or between Hybrid Mail operators. The Technical Specification defines a XML Schema Definition (XSD) describing the data stream.
The description is based upon the XML (eXtended Mark-up Language) definition of rules and semantics for defining an XSD. The purpose of this is to offer a generalised syntax description that can provide seamless integration with a number of existing applications generating data that is liable to be forwarded to or from a Hybrid Mail operator.
The use of an XSD will ensure that the documents confirm to the standard defined and that the output has the correct syntax. Software manufacturers can use an XSD to program applications that will produce "correct" outputs.
This Technical Specification defines the syntax for creating a data stream that will eventually be converted into a deliverable. The overall object (a batch) can be divided into one or more objects that again can be divided into objects. The hierarchy includes bundles that contains a common part and letters. Each object has a number of characteristics attached to it.
This diagram shows the structure of a HML (Hybrid Mail Language) document: each letter is self-contained (contains all the necessary information to be delivered on a certain destination).