ETSI TR 119 530 V1.1.1 (2019-02)

TECHNICAL REPORT
Electronic Signatures and Infrastructures (ESI);
Registered Electronic Mail (REM);
Feasibility study: Interoperability profile between
ETSI EN 319 532-based REM systems
and PReM-based systems
2 ETSI TR 119 530 V1.1.1 (2019-02)

Reference
DTR/ESI-0019530
Keywords
e-delivery services, registered e-delivery
services, registered electronic mail

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TR 119 530 V1.1.1 (2019-02)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 4
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols, abbreviations and terminology . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
3.4 Terminology . 8
4 Goals and approaches . 8
5 Gap analysis . 9
5.1 REM - ETSI TS 102 640 vs ETSI EN 319 532 . 9
5.1.1 Introduction. 9
5.1.2 Changes on terms and boundary roles . 9
5.1.3 Changes on event and evidence types . 12
5.1.4 Changes on messages. 15
5.1.4.1 Introduction . 15
5.1.4.2 Metadata implemented as optional extension headers in REM messages . 16
5.1.4.3 Differences in the outermost MIME section header of a REM message. 18
5.1.4.4 Differences in the signed data MIME section header of a REM message . 19
5.1.4.5 Differences in the Introduction MIME section header of a REM message . 19
5.1.4.6 Differences in the original message MIME section header of a REM message . 20
5.1.4.7 Differences in the extensions MIME section header of a REM message . 21
5.1.4.8 Differences in the evidence MIME section header of a REM message . 22
5.1.4.9 Differences in the signature MIME section header of a REM message . 24
5.1.5 Changes on evidence structure and semantic . 25
5.1.6 Changes on trusting . 32
5.2 PReM - UPU S.52 2008 vs UPU S.52 CEN/TS 16326 (2013) . 37
5.2.1 Introduction. 37
5.2.2 Changes on flows . 37
5.2.3 Changes on messages. 39
5.2.4 Changes on evidence structure and semantic . 40
5.2.5 Changes on signature . 41
5.2.6 Changes on trusting . 41
6 Recommendation for follow-up activities . 42
6.1 Overview . 42
6.2 UPU-side activities . 42
6.2.1 Update of references . 42
6.2.2 Update of security techniques . 43
6.2.3 Adaptation of flows . 43
6.2.4 Adaptation of message formats . 43
6.2.5 Adaptation of evidence format. 44
6.2.6 Update of policy considerations . 44
6.3 ETSI-side activities . 45
7 Conclusions . 47
History . 48

ETSI
4 ETSI TR 119 530 V1.1.1 (2019-02)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Electronic Signatures and Infrastructures
(ESI).
The present document is a standalone document and it is closely tied to ETSI EN 319 522 [i.21] and ETSI
EN 319 532 [i.22].
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
Registered Electronic Mail (REM) Service is a particular type of an "Electronic Registered Delivery Service" (ERDS).
Standard email, used as backbone, makes interoperability smooth and increases usability. At the same time, the
application of additional security mechanisms ensures integrity, confidentiality and non-repudiation (of submission,
consignment, handover, etc.), and protects against risk of loss, theft, damage and any illegitimate modification of user
content. ETSI EN 319 532 [i.22] gives technical specification for REM Service.
Postal Registered Electronic Mail (PReM) is an electronic version of the conventional postal registered mail service. It
can be provided to the customers by entities called "designated operators" that are part of a program called "Secure
electronic Postal Services (SePS)". It provides strong authentication, confidentiality and integrity protecting the
message, and non-repudiation attributes to evidence, events and operations. UPU S52-2 [i.25] provides functional
specification for PReM.
ETSI
5 ETSI TR 119 530 V1.1.1 (2019-02)
The currently existing PReM specifications were built based on ETSI TS 102 640 [i.23], which is a historical technical
specification for REM, originally published in 2008 and last updated in 2011. The latest REM technical specification is
ETSI EN 319 532 [i.22], published in 2018, which builds on the more general specification of Electronic Registered
Delivery Service (ERDS) defined in ETSI EN 319 522 [i.21]. The new ETSI EN 319 532 [i.22] is an evolution of the
older ETSI TS 102 640 [i.23]. The new REM standard was created based on ETSI TS 102 640 [i.23], but it is
restructured to align with the ERDS standard, and contains a number of necessary changes and updates. The changes of
Evidence (especially in formats) in ERDS (ETSI EN 319 522 [i.21]) did not allow the definition of a new ERDS/PReM
interoperability profile like that defined in ETSI TS 102 640 [i.23]. Such interoperability profile was based on the
PReM S52-1 [i.24] specification at the time. Since its publication the UPU S52-1 [i.24] has also been updated in UPU
S52-2 [i.25], introducing changes in the workflows, messages and evidences.
The present document aims to provide a feasibility study that will pave the way for the update of UPU S52-2 /
CEN/TS 16326 [i.25] and eventually the production of the interoperability profile between systems based on ETSI
EN 319 522 [i.21] and ETSI EN 319 532 [i.22], and systems based on PReM [i.25] properly updated as recommended
in the present document.
ETSI
6 ETSI TR 119 530 V1.1.1 (2019-02)
1 Scope
The present document represents a feasibility study for an interoperability profile between systems based on ETSI
EN 319 522 [i.21] / ETSI EN 319 532 [i.22] ERDS/REMS specification and UPU S52-2 PReM specification [i.25].
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI EN 319 532-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 1: Framework and architecture".
[i.2] ETSI EN 319 532-2: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 2: Semantic contents".
[i.3] ETSI EN 319 532-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 3: Formats".
[i.4] ETSI EN 319 522-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 1: Framework and architecture".
[i.5] ETSI EN 319 522-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 2: Semantic contents".
[i.6] ETSI EN 319 522-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 3: Formats".
[i.7] ETSI EN 319 521: "Electronic Signatures and Infrastructures (ESI); Policy and security
requirements for Electronic Registered Delivery Service Providers".
[i.8] ETSI EN 319 531: "Electronic Signatures and Infrastructures (ESI); Policy and security
requirements for Registered Electronic Mail Service Providers".
[i.9] ETSI TS 102 640-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM); Part 1: Architecture".
[i.10] ETSI TS 102 640-2: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM); Part 2: Data requirements, Formats and Signatures for REM".
[i.11] ETSI TS 102 640-6-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic
Mail (REM); Part 6: Interoperability Profiles; Sub-part 1: REM-MD UPU PReM Interoperability
Profile".
[i.12] ETSI EN 319 132-1: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures;
Part 1: Building blocks and XAdES baseline signatures".
ETSI
7 ETSI TR 119 530 V1.1.1 (2019-02)
[i.13] ETSI TS 101 903: "Electronic Signatures and Infrastructures (ESI); XML Advanced Electronic
Signatures (XAdES)".
[i.14] ETSI TS 103 171 (V2.1.1): "Electronic Signatures and Infrastructures (ESI); XAdES Baseline
Profile".
[i.15] IETF RFC 7522: "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client
Authentication and Authorization Grants".
[i.16] ETSI TS 102 176-1: "Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters
for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms".
[i.17] ETSI TS 102 231: "Electronic Signatures and Infrastructures (ESI); Provision of harmonized
Trust-service status information".
[i.18] ETSI TS 119 312: "Electronic Signatures and Infrastructures (ESI); Cryptographic Suites".
[i.19] ETSI TS 119 612: "Electronic Signatures and Infrastructures (ESI); Trusted Lists".
[i.20] IETF RFC 2046: "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types".
[i.21] ETSI EN 319 522 (all parts): "Electronic Signatures and Infrastructures (ESI); Electronic
Registered Delivery Services".
[i.22] ETSI EN 319 532 (all parts): "Electronic Signatures and Infrastructures (ESI); Registered
Electronic Mail (REM) Services".
[i.23] ETSI TS 102 640 (all parts): "Electronic Signatures and Infrastructures (ESI); Registered
Electronic Mail (REM)".
[i.24] UPU S52-1: "Functional specification for postal registered electronic mail".
NOTE: This is version 1 of the UPU S52 specification; date of adoption is 30 October 2008.
[i.25] UPU S52-2 / CEN/TS 16326: "Functional specification for postal registered electronic mail".
NOTE: This is version 2 of the UPU S52 specification; date of adoption is 9 April 2013.
[i.26] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on
electronic identification and trust services for electronic transactions in the internal market and
repealing Directive 1999/93/EC.
[i.27] ETSI TS 101 862: "Qualified Certificate profile".
[i.28] ETSI EN 319 412 (all parts): "Electronic Signatures and Infrastructures (ESI); Certificate
Profiles".
[i.29] IETF RFC 5322: "Internet Message Format".
[i.30] IETF RFC 3851: "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message
Specification".
[i.31] IETF RFC 5751: "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message
Specification".
[i.32] ETSI EN 319 132 (all parts): "Electronic Signatures and Infrastructures (ESI); XAdES digital
signatures".
[i.33] IETF RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3".
[i.34] ETSI TS 102 640-5: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM); Part 5: REM-MD Interoperability Profiles".
[i.35] IETF RFC 2822: "Internet Message Format".
[i.36] CWA 14169: "Secure signature-creation devices "EAL 4+"".
ETSI
8 ETSI TR 119 530 V1.1.1 (2019-02)
[i.37] CEN EN 419211 (parts 1 to 6): "Protection profiles for secure signature creation device".
[i.38] ETSI TS 102 640 (V1.1.1) (parts 1 to 3): "Electronic Signatures and Infrastructures (ESI);
Registered Electronic Mail (REM); Architecture, Formats and Policies".
3 Definition of terms, symbols, abbreviations and
terminology
3.1 Terms
For the purposes of the present document, the terms given in ETSI EN 319 522 [i.21], ETSI EN 319 532 [i.22], ETSI
TS 102 640-6-1 [i.11], UPU PReM S52-1 [i.24] and UPU S52-2 / CEN/TS 16326 [i.25] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI EN 319 522 [i.21], ETSI EN 319 532 [i.22],
ETSI TS 102 640-6-1 [i.11], UPU PReM S52-1 [i.24] and UPU S52-2 / CEN/TS 16326 [i.25] apply.
3.4 Terminology
For the purposes of the present document, the terminology given in ETSI EN 319 522 [i.21], ETSI EN 319 532 [i.22],
ETSI TS 102 640-6-1 [i.11], UPU PReM S52-1 [i.24] and UPU S52-2 / CEN/TS 16326 [i.25] apply.
4 Goals and approaches
This feasibility study includes:
• A gap analysis between the new ETSI EN 319 522 [i.21] / ETSI EN 319 532 [i.22] and the historical ETSI
TS 102 640 [i.23] regarding those aspects covered within UPU S52-2 / CEN/TS 16326 [i.25].
• A gap analysis between the latest UPU S52-2 [i.25] and the obsolete UPU S52-1 [i.24] regarding those aspects
affecting the interoperability with ETSI REM-based systems.
• Recommendations for updating UPU S52-2 / CEN/TS 16326 [i.25] specifications in the light of the gap
analysis aforementioned. This would speed up the update of the UPU S52-2 / CEN/TS 16326 [i.25]
specifications as the members of the UPU and CEN TC 331 could start their work based on these
recommendations.
• Recommendations for the production of the interoperability profile between the new UPU S52-2 /
CEN/TS 16326 [i.25] and the ETSI EN 319 532 [i.22], which would speed up the production of such profile
once the updated UPU S52-2 / CEN/TS 16326 [i.25] is published.
ETSI
9 ETSI TR 119 530 V1.1.1 (2019-02)
5 Gap analysis
5.1 REM - ETSI TS 102 640 vs ETSI EN 319 532
5.1.1 Introduction
ETSI EN 319 522 [i.21] and ETSI EN 319 532 [i.22] include relevant modifications to certain aspects defined in ETSI
TS 102 640 [i.23] (among which, for instance, change in schema for evidence, definition of new evidence, changes in
the contents of the messages, etc.), resultant of comments arrived from stakeholders and findings of an ESI team that
worked before the start of the STF, in the identification of fixes required by the aforementioned ETSI TS.
The following clauses from 5.1.2 to 5.1.6 outline, in a structured way, all these aspects.
The tables contained in the aforementioned clauses summarize the semantics and syntactical differences between the
definitions specified in ETSI EN 319 532-1 [i.1] and the definitions specified in ETSI TS 102 640-1 [i.9].
Only the definitions that are relevant for the present gap analysis appear in the tables. All the terms used but undefined
in the tables may be found in the respective specification of provenance.
5.1.2 Changes on terms and boundary roles
Table 1 and Table 2 summarize similarities and differences between definitions, components and roles of ETSI
EN 319 532-1 [i.1] and ETSI TS 102 640-1 [i.9].
ETSI
10 ETSI TR 119 530 V1.1.1 (2019-02)
Table 1: Definitions defined in ETSI EN 319 532-1 [i.1]
and ETSI TS 102 640-1 [i.9], similarities and differences
Terms as per
Definitions as per
ETSI EN 319 532-1 [i.1]
# ETSI TS 102 640-1 [i.9] Definitions as per ETSI EN 319 532-1 [i.1]
Terms as per
ETSI TS 102 640-1 [i.9]
Consignment Act of making the user content available to the
1 recipient within the boundaries of the electronic
N/A
registered delivery service
ERDS evidence Signed data created within a REM-MD, Data generated by the electronic registered
2 REM-MD evidence which proves that a certain event has delivery service, which aims to prove that a
occurred at a certain time certain event has occurred at a certain time
3 Handover Act of having the user content successfully
cross the border of the recipient's electronic
N/A
registered delivery service towards the
recipient's ERD user agent/application
4 original message e-mail message generated by the Data including user content and submission
Sender's User Agent or under the metadata
original message
Sender's technical/legal responsibility
(i.e. outside of the REM-MD), which
may be signed by the Sender
5 Registered Electronic Mail Set of technical and physical Electronic registered delivery service which
Service (REMS) components, personnel, policies and builds on the formats, protocols and
REM Management Domain processes that provide REM services mechanisms used in ordinary e-mail messaging
(REM-MD)
6 Registered Electronic Mail See note. Entity which provides registered electronic mail
Service Provider (REMSP) service
N/A
7 REM dispatch REM-MD Envelope containing the Data composed of a user content, some ERDS
REM dispatch Original Message and related REM-MD relay metadata and ERDS evidence, in the form
Evidence of a REM envelope
8 REM envelope Signed structure generated by the Signed data structure generated by the
REM-MD which envelopes an Original registered electronic mail service which contains
REM-MD envelope
message and/or REM-MD Evidence any of the user content, ERDS relay metadata
and/or ERDS evidence
9 REM message Message generated by the REM MD Data composed of an optional user content,
under the REM MD sole technical/legal ERDS relay metadata and zero or more ERDS
REM-MD Message
responsibility (i.e. inside of the REM evidence, in the form of a REM envelope
MD)
10 REM payload REM message which contains the user content
and some ERDS relay metadata
11 REM interoperability domain Any domain where a common set of Homogeneous operational space consisting of a
REM Policy Domain rules (e.g. legal, company policy or set of REMSPs able to properly interoperate
agreement) is enforced for the among themselves
provision of REM services
12 REM interoperability domain Set of rules (e.g. legal, company policy Set of rules defining a REM interoperability
rules or agreement) enforced for the domain
REM Policy provision of REM Services
13 REMS notification Data composed of ERDS relay metadata and
N/A zero or more ERDS evidence, in the form of a
REM envelope, which includes a reference to
the user content to be delivered
14 REMS receipt Data composed of ERDS relay metadata and
N/A ERDS evidence, in the form of a REM envelope
15 user content Original data produced by the sender which has
to be delivered to the recipient
N/A
16 N/A Message object handled by a
REM-MD. This is a REM-MD Message,
REM Object
REM-Dispatch or Original message
NOTE: In some form and in some case, REMSP is mapped to REM-MD.

ETSI
11 ETSI TR 119 530 V1.1.1 (2019-02)
Table 2: Components/roles defined in ETSI EN 319 532-1 [i.1] and ETSI TS 102 640-1 [i.9],
similarities and differences
Components as per ETSI
EN 319 532-1 [i.1] Description of roles as per ETSI Description of components as per ETSI
#
Roles as per ETSI TS 102 640-1 [i.9] EN 319 532-1 [i.1]
TS 102 640-1 [i.9]
REMS message delivery agent Role that supports the transfer of REM REMS message delivery agent is equivalent
Objects to REM Recipient's and REM to the component "ERDS Message delivery
Sender's REM Message Store either system" (defined in ETSI EN 319 522-1 [i.4]):
directly or via the REM Object Relay this component grants that the user content
1 REM-MD Message Transfer Interface into another REM-MD or via a submitted by the sender is made available to
REM-MD Message Gateway. the intended recipient. Note that this does not
Agent
necessarily imply a transfer of the data (e.g.
the delivery can consist in making existing
data available to the recipient).
REMS evidence provider Role that issues REM-MD Evidence. REM-MD Evidence Provider is equivalent to
REM-MD Evidence Provider the component "ERDS Evidence provider"
2 (defined in ETSI EN 319 522-1 [i.4]): this
component produces the ERDS evidence
upon completion of specific delivery events.
REMS evidence repository REM-MD repository: Role that supports REMS evidence repository is equivalent to the
REMS message store the storage of REM Objects, REM-MD component "ERDS Evidence repository"
Evidence and any other, which will be (defined in ETSI EN 319 522-1 [i.4]): this
REM-MD repository
message archive accessed by reference. component grants the persistence of ERDS
REM Message Store evidence for a period of time which depends
message archive: optional role that on the specific policies of the service. Storing
supports storage of REM Objects and of the ERDS evidence can be performed by a
REM-MD Evidence, as required for later third party service, outside the ERDS.
3 use for evidential or any other legally
admitted purposes, at the relevant In addition to the general ERDS components,
REM-MD for an indefinite or definite time a REMS also provides a REMS message
period, to be accessed once or many store component. A REMS message store is
times by one or more entities. allocated to the senders and recipients, and is
securely accessible by senders and recipients
REM Message Store: role that supports respectively to retrieve REM messages
the storage of REM Objects. In other addressed to them.
words the set of mailboxes of the users.
REMS user directory In interoperability profile ETSI REMS user directory is equivalent to the
TS 102 640-6-1 [i.11] the PReM Directory component "ERDS User directory" (defined in
REM-MD repository
Service was mapped inside the REM-MD ETSI EN 319 522-1 [i.4]): this component is
repository role. used to translate the unique identification of a
recipient, possibly augmented by further
4 metadata, into a delivery endpoint. The same
recipient can correspond to more delivery
endpoints, depending on metadata (e.g. user
content and evidence, or even different types
of user content, can be directed to different
endpoints).
5 REMS Role that supports the verification of This task is performed generally by REMS.
REM-MD Evidence Verifier REM-MD Evidence.
6 Registered Electronic Mail Role that supports the transfer of REM Entity which provides registered electronic
Service Provider (REMSP) objects to conventional e-mail (e.g. mail service. In the most general case a
REM-MD Message Gateway Internet) services and physical postal service provider acting as a REMSP could
delivery services. also be able to communicate using other
formats and protocols which are different from
REM, and thus provide interconnection with
other types of ERDSs. An intermediate ERDS
could also provide such protocol conversion,
thereby acting as a gateway between a REM
and a non-REM ERDS.
ETSI
12 ETSI TR 119 530 V1.1.1 (2019-02)
Components as per ETSI
EN 319 532-1 [i.1] Description of roles as per ETSI Description of components as per ETSI
#
Roles as per ETSI TS 102 640-1 [i.9] EN 319 532-1 [i.1]
TS 102 640-1 [i.9]
7 ERD User Agent/Application Entity by which REM Senders, REM System consisting of software and/or
(ERD-UA) Recipients participate in the exchange of hardware components by which senders and
REM Objects and Third Parties may recipients participate in the exchange of data
REM User Agent (REM-UA)
access REM Objects. with electronic registered delivery service
providers.
8 recipient Physical or legal entity legally responsible Natural or legal person to which the user
for the mailbox to which the original content is addressed.
REM Recipient
message is addressed.
9 sender Physical or legal entity legally responsible Natural or legal person that has submitted the
REM Sender for the mailbox from which the original user content.
message has been sent.
10 N/A Party authorized to access REM Objects
and REM-MD Evidence for specific
REM Third Party
purposes.
5.1.3 Changes on event and evidence types
Table 3 and Table 4 summarize similarities and differences between events, flows and interfaces of ETSI
EN 319 532-1 [i.1] and ETSI TS 102 640-1 [i.9].
These events are mentioned in clause 7 of ETSI TS 102 640-6-1 [i.11] on both the following directions of the flow:
1) Table 4 [i.11]: GAP Analysis - Transmission/Relay/Delivery - REM-MD  DO
2) Table 5 [i.11]: GAP Analysis - Transmission/Relay/Delivery - DO  REM-MD
3) Table 6 [i.11]: GAP Analysis - Retrieval - REM-MD  DO
4) Table 7 [i.11]: GAP Analysis - Retrieval - DO  REM-MD
In fact, the meaning that the events assume at gateway level has to be considered, respectively, in accordance and in the
order in which they appear in the flows described in Table 4, Table 5, Table 6 and Table 7 of ETSI
TS 102 640-6-1 [i.11].
ETSI
13 ETSI TR 119 530 V1.1.1 (2019-02)
Table 3: Events on flows interfaces in ETSI EN 319 532-1 [i.1] and ETSI TS 102 640-1 [i.9],
similarities and differences
Events as per
ETSI EN 319 532-1 [i.1] Description of events as per ETSI Description of events as per ETSI
#
Events as per TS 102 640-1 [i.9] EN 319 532-1 [i.1]
ETSI TS 102 640-1 [i.9]
1 6.2.2 B. Events related to the relay One REM Object sent by the REM Sender's "The receiving REMS has accepted
between REMSs - Table 4 - B.1 REM-MD and successfully received by the the relayed REM message containing
RelayAcceptance REM Recipient's REM-MD, was accepted by user content, and the REMSP takes
6.2.2 Event B.1 - R-REM-MD the latter responsibility for handling it according
to the requirements in the present
Acceptance
document and the policy rules."
2 6.2.2 B. Events related to the relay One REM Object sent by the REM Sender's "The receiving REMS has rejected the
between REMSs - Table 4 - B.2 REM-MD and successfully received by the relayed REM message containing user
RelayRejection REM Recipient's REM-MD, was rejected by content. The receiving REMS shall
the latter due to policy, formal or technical inform the sending REMS about the
6.2.2 Event B.2 - R-REM-MD
Rejection reasons reason(s) for the rejection."
3 6.2.2 B. Events related to the relay It was impossible to deliver within a given time "The sending REMS was unable to
between REMSs - Table 4 - B.3 period a REM Object to the REM Recipient's relay the REM message containing
RelayFailure REM-MD due to technical errors and/or other user content to the receiving REMS
problems within a given time period, or the
6.2.2 Event B.3 - Expiration of time to
receiving REMS did not return ERDS
deliver to R-REM-MD
evidence about the acceptance or
rejection of the REM message within
that time period."
4 6.2.4 D. Events related to the REM Object was delivered to the REM "R-REMS has made the user content
consignment - Table 6 - D.1 Recipient's mailbox at a specific time available to the recipient".
ContentConsignment
6.2.3 Event C.1 - Message Delivery
5 6.2.4 D. Events related to the REM Object could not be delivered to the "The REMS could not make the user
consignment - Table 6 - D.2. REM Recipient's mailbox within a given time content available to the recipient within
ContentConsignmentFailure period due to technical errors and/or other a given time period, or the REMS did
6.2.3 Event C.2 - Expiration of time reasons; Furthermore, no prove of delivery not receive ERDS evidence within a
within a given period exists given time period about the successful
to deliver message
or unsuccessful consignment of the
user content from the other REMS to
which it had relayed the user content."
6 6.2.5 E. Events related to the REM Object present in the REM Recipient's "The user content has successfully
handover to the recipient - Table 7 - mailbox was retrieved by the REM Recipient passed through the REM MRI from the
E.1. ContentHandover REMS to the client under the
responsibility of the recipient."
6.2.3 Event F.1 (mailbox) -Retrieval
7 6.2.5 E. Events related to the REM Object present in the REM Recipient's "The user content did not pass through
handover to the recipient - Table 7 - mailbox was not retrieved by the REM the REM MRI within a given time".
E.2. ContentHandoverFailure Recipient's mail client within a given period
6.2.3 Event F.2 (mailbox) - Expiration
of time for Retrieval
In ERDS/REMS specification there is not a specific name definition for any evidence generated in the flowing of the
information. Rather, any evidence is fully identified by the event causing it.
Table 4 outlines the differences and mapping with the evidence set, concerning the restricted scope of the
interoperability profile, defined in ETSI TS 102 640-2 [i.10]. ERDS has to be interpreted as a synonym of REMS.
ETSI
14 ETSI TR 119 530 V1.1.1 (2019-02)
Table 4: Evidence on flows interfaces defined in ETSI EN 319 532-1 [i.1] and ETSI TS 102 640-2 [i.10],
similarities and differences
Relevant evidence as per ETSI
EN 319 522-1 [i.4] Description of evidence as per ETSI Description of evidence as per ETSI
#
Relevant evidence as per ETSI TS 102 640-2 [i.10] EN 319 522-1 [i.4]
TS 102 640-2 [i.10]
1 Evidence for: Evidence to prove that one REM-MD The related evidence attests that, in situations
6.2.2 B. Events related to the relay Message/REM Dispatch sent by the where several ERDSs are co-operating (as in
between REMSs - Table 4 - B.1 sender's REM-MD was successfully 4-corner model and extended model above),
RelayAcceptance received by the recipient's REM-MD that an intermediate or the recipient's ERDS has
6.2.2 B. Events related to the relay accepted/rejected it. accepted (B.1)/rejected (B.2) one ERD
between REMSs - Table 4 - B.2 message sent by the previous ERDS in the
RelayRejection aforementioned chain.
5.1.2 Evidence
RelayToREMMDAcceptanceRejectio
n
2 Evidence for: Evidence to prove that it was impossible The related evidence attests that, at the time
6.2.2 B. Events related to the relay to deliver a REM-MD Message/REM specified in the evidence, it was impossible
between REMSs - Table 4 - B.3 Dispatch within a given time period to the (or it is clear that it will be impossible) to
RelayFailure recipient's REM-MD due to technical deliver an ERD message within a given time
5.1.3 Evidence errors and/or other problems. period to either an intermediate ERDS
RelayToREMMDFailure provider or to the recipient's ERDS provider
due to technical errors and/or other problems.
3 Evidence for: Evidence to prove that the REM-MD The related evidence attests that:
6.2.4 D. Events related to the Message/REM Dispatch was delivered to
consignment - Table 6 - D.1 the recipient's mailbox or, OPTIONALLY, 1) (D.1) the user content, at a specific time
ContentConsignment to a delegate's mailbox at a specific time indicated by the evidence, was made
6.2.4 D. Events related to the or that it was not possible to deliver it available for the recipient - through proper
consignment - Table 6 - D.2. within a given time period: identification and authentication - within the
ContentConsignmentFailure boundaries of the ERDS;
5.1.4 Evidence 1) The recipient's REM-MD successfully
DeliveryNonDeliveryToRecipient deposited/was not able to deposit within 2) (D.2) the user content could not be made
a given time period a REM-MD available to the recipient within a given time
Message/REM Dispatch into the period.
recipient's or, OPTIONALLY, a
• The recipient's ERDS was not able
delegate's REM mailbox.
to consign the user content to the
recipient. In this case the evidence is
2) The sender's REM-MD did not receive
produced by the R-ERDS.
within a given time period from the
• A relaying ERDS did not receive
recipient's
within a given time period from the
REM-MD a REM-MD Evidence of
relayed ERDS an evidence of
successful/unsuccessful delivery.
successful or unsuccessful
consignment. In this case it is the
relaying ERDS that creates the
evidence with the suitable reason
code.
4 Evidence for: Evidence to prove that the REM-MD The related evidence attests that:
6.2.5 E. Events related to the Message/REM Dispatch present in the
handover to the recipient - Table 7 - recipient's mailbox was retrieved/non 1) (E.1) the user content at a specific time
E.1. ContentHandover retrieved within a given period - by the indicated by the evidence crossed the R-
6.2.5 E. Events related to the recipient or, OPTIONALLY, by a ERDS border and was handed to the recipient
handover to the recipient - Table 7 - recipient's delegate. UA/Application upon proper authentication.
E.2. ContentHandoverFailure
2) (E.2) the user content could not cross the
5.1.6 Evidence
RetrievalNonRetrievalByRecipient R-ERDS border toward the recipient's ERD-
UA after a certain number of attempts or a
timeout as specified by the applicable
policies.
ETSI
15 ETSI TR 119 530 V1.1.1 (2019-02)
5.1.4 Changes on messages
5.1.4.1 Introduction
The following clauses summarize the semantics and syntactical differences between the REM Messages components
specified in ETSI EN 319 532-3 [i.3] and the REM Messages components specified in ETSI TS 102 640-2 [i.10].
All the aforementioned tables have the same format, explained in the following paragraphs.
Cells in first column (#) numerate the rows so that from one cell of the table a reference can be made to a certain row.
Cells in second column are split in two rows. The first row ( as per ETSI
EN 319 532-3 [i.3]) identifies the component under analysis and specified [i.3]. The second row ( compared> as per ETSI TS 102 640-2 [i.10]) identifies the component under analysis and specified [i.10].
Cells in third column (In as per ETSI TS 102 640-2 [i.10]) shows details of the
component as specified in ETSI TS 102 640-2 [i.10]. These details can include simple values of the components, or the
content model (sub-components).
Cells in fourth column (In as per ETSI EN 319 532-3 [i.3]) shows details of the
component as specified in ETSI EN 319 522-3 [i.6]. In addition to these details, cells in this column include, most of the
times, rationales and/or highlights of specific differences between this component in the REM Message analysed in the
table and the corresponding component in the corresponding REM Message as specified in ETSI TS 102 640-2 [i.10].
ETSI
16 ETSI TR 119 530 V1.1.1 (2019-02)
5.1.4.2 Metadata implemented as optional extension headers in REM messages
Table 5 compares metadata:
• whose semantics and syntax have been defined in ETSI TS 102 640-2 [i.10] with metadata;
• whose incorporation, as optional extension headers to REM messages, has been specified in ETSI EN 319 532-3 [i.3], and which are based on;
• the semantics that has been defined in ETSI EN 319 522-2 [i.5]; and
• the formats that have been defined in ETSI EN 319 522-3 [i.6].
Table 5: Optional extension header fields defined in ETSI EN 319 532-3 [i.3] and ETSI TS 102 640-2 [i.10], similarities and differences
Optional extension header fields as per ETSI
EN 319 532-3 [i.3] In Outermost MIME header as
# In Outermost MIME header as per ETSI EN 319 532-3 [i.3]
Optional extension header fields as per ETSI per ETSI TS 102 640-2 [i.10]
TS 102 640-2 [i.10]
REM-Message-Type ETSI TS 102
...