ETSI TS 119 534-2 V1.1.1 (2019-02)

TECHNICAL SPECIFICATION
Electronic Signatures and Infrastructures (ESI);
Testing Conformance and Interoperability of
Registered Electronic Mail Services;
Part 2: Test suites for interoperability testing of
providers using same format and transport protocols

2 ETSI TS 119 534-2 V1.1.1 (2019-02)

Reference
DTS/ESI-0019534-2
Keywords
interoperability, registered electronic mail, testing

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 TS 119 534-2 V1.1.1 (2019-02)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Technical approach. 8
4.1 Components of test cases and their identifiers . 8
4.2 Adding new test cases to the test suite . 9
5 Scenarios . 10
5.1 Introduction . 10
5.2 Abbreviations used in tables defining scenarios . 11
5.3 Black-box model scenarios. 12
5.3.1 Introduction. 12
5.3.2 Scenarios for Store and Forward style . 12
5.3.3 Scenarios for Store and Notify style . 24
5.4 Scenarios for 4-corner model . 29
5.4.1 Introduction. 29
5.4.2 Scenarios for Store&Forward to Store&Forward . 29
5.4.3 Scenarios for Store&Forward to Store&Notify . 36
5.4.4 Scenarios for Store&Notify to Store&Forward . 46
5.5 Scenarios for extended model . 58
5.5.1 Introduction. 58
5.5.2 Scenarios for S&F->S&F->S&F . 58
5.5.3 Scenarios for S&F -> S&N -> S&F . 67
6 REM Messages instances . 77
6.1 Introduction and technical approach. 77
6.2 Combinations of fields for headers in REM envelopes . 77
6.2.1 Introduction. 77
6.2.2 Combinations of fields for the outermost MIME header . 77
6.2.3 Combinations of fields for the signed data MIME header . 84
6.2.4 Combinations of fields for the REMS introduction section . 84
6.2.4.1 Introduction . 84
6.2.4.2 Combinations of fields for the REMS introduction MIME header . 84
6.2.4.3 Combinations of fields for the multipart/alternative free text subsection header . 84
6.2.4.4 Combinations of fields for the multipart/alternative html subsection header . 84
6.2.5 Combinations of fields for the original message MIME section header . 84
6.2.6 Combinations of fields for one REMS extension MIME section header . 85
6.2.7 Combinations of fields for one ERDS evidence MIME section header . 86
6.2.7.1 Combinations of fields for one XML ERDS evidence MIME section header . 86
6.2.7.2 Combinations of fields for one PDF ERDS evidence MIME section header . 87
6.2.8 Combinations of fields for the REMS signature MIME section header . 88
6.3 Instances of REM payload. 89
6.4 Instances of REMS notification . 95
6.5 Instances of REMS receipts. 99
6.6 Instances of REM dispatch . 100
7 Other named sets . 104
ETSI
4 ETSI TS 119 534-2 V1.1.1 (2019-02)
7.1 Named sets of participating REMSs . 104
7.2 Named sets of additional requirements . 104
7.3 Named sets of entities in receiving side . 104
8 Test cases definition . 105
8.1 Introduction . 105
8.2 Test cases for black-box model . 106
8.2.1 Test cases for Store&Forward style of operation . 106
8.2.1.1 Introduction . 106
8.2.1.2 Test cases for scenario REM_SF#1 . 107
8.2.1.3 Test cases for scenario REM_SF#2 . 107
8.2.1.4 Test cases for scenario REM_SF#3 . 108
8.2.1.5 Test cases for scenario REM_SF#4 . 108
8.2.1.6 Test cases for scenario REM_SF#5 . 108
8.2.1.7 Test cases for scenario REM_SF#6 . 109
8.2.1.8 Test cases for scenario REM_SF#7 . 109
8.2.1.9 Test cases for scenario REM_SF#8 . 110
8.2.1.10 Test cases for scenario REM_SF#9 . 110
8.2.1.11 Test cases for scenario REM_SF#10 . 111
8.2.1.12 Test cases for scenario REM_SF#11 . 111
8.2.1.13 Test cases for scenario REM_SF#12 . 112
8.2.1.14 Test cases for scenario REM_SF#13 . 112
8.2.2 Test cases for Store&Notify style of operation . 113
8.2.2.1 Rules for REM messages . 113
8.2.2.2 Rules for failure reasons . 113
8.3 Test cases for 4-corner model . 113
8.3.1 Introduction and general rules . 113
8.3.2 Test cases for Store&Forward to Store&Forward scenarios . 114
8.3.2.1 Rules for REM messages . 114
8.3.2.2 Rules for failure reasons . 114
8.3.3 Test cases for Store&Forward to Store&Notify scenarios . 115
8.3.3.1 Rules for REM messages . 115
8.3.3.2 Rules for failure reasons . 115
8.3.4 Test cases for Store&Notify to Store&Forward scenarios . 115
8.3.4.1 Rules for REM messages . 115
8.3.4.2 Rules for failure reasons . 115
8.4 Test cases for extended model . 116
8.4.1 Test cases for scenarios S&F->S&F->S&F . 116
8.4.1.1 Rules for REM messages . 116
8.4.1.2 Rules for failure reasons . 116
8.4.2 Test cases for scenarios S&F->S&N->S&F . 116
8.4.2.1 Rules for REM messages . 116
8.4.2.2 Rules for failure reasons . 116
History . 117

ETSI
5 ETSI TS 119 534-2 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 Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and
Infrastructures (ESI).
The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.1].
Modal verbs terminology
In the present document "shall", "shall not", "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.

ETSI
6 ETSI TS 119 534-2 V1.1.1 (2019-02)
1 Scope
The present document defines:
1) A test suite for supporting interoperability tests within the field of Registered Electronic Mail (REM
hereinafter) as specified in ETSI EN 319 532 parts 1 [3], 2 [4], 3 [5] and 4 [6]. The test suite defines test cases
for the following environments:
- Environments that correspond to the basic model as defined in ETSI EN 319 532-1 [3] where sender and
all the entities at receiving side are subscribed to the same REMS. Test cases are defined for REMSs
operating Store&Forward and for REMSs operating Store&Notify styles.
- Environments that correspond to the 4-corner model as defined in ETSI EN 319 532-1 [3] where sender
is subscribed to one REMS and the entities at receiving side are subscribed to another one, and no
intermediate REMS is required for relaying REM messages between them. Test cases are defined for
covering the three possible different combinations of styles, namely Store&Forward to Store&Forward,
Store&Forward to Store&Notify, and Store&Notify to Store&Forward.
- Environments that correspond to the extended model as defined in ETSI EN 319 532-1 [3] where sender
is subscribed to one REMS and the entities at receiving side are subscribed to another one, and
intermediate REMSs are required for relaying REM messages between them. Test cases are defined for
covering two different combinations of styles, namely Store&Forward to Store&Forward to
Store&Forward, Store&Forward to Store&Notify to Store&Forward.
2) A mechanism for documenting new test cases and expanding the aforementioned test suite.
2 References
2.1 Normative 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.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
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 necessary for the application of the present document.
[1] ETSI EN 319 522-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 1: Framework and Architecture".
[2] ETSI EN 319 522-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 2: Semantic contents".
[3] ETSI EN 319 532-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 1: Framework and Architecture".
[4] ETSI EN 319 532-2: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 2: Semantic Contents".
[5] ETSI EN 319 532-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 3: Formats".
[6] ETSI EN 319 532-4: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 4: Interoperability profiles".
[7] IETF RFC 8118: "The application/pdf Media Type".
ETSI
7 ETSI TS 119 534-2 V1.1.1 (2019-02)
[8] IETF RFC 2046: "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types".
[9] IETF RFC 2183: " Communicating Presentation Information in Internet Messages: The
Content-Disposition Header Field".
[10] IETF RFC 5751: "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message
Specification".
[11] IETF RFC 5322: "Internet Message Format".
[12] IETF RFC 2854: "The 'text/html' Media Type".
[13] IETF RFC 7303: "XML Media Types".
[14] IETF RFC 2045: "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies".
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 TS 119 534-1: "Electronic Signatures and Infrastructures (ESI); Testing Conformance and
Interoperability of Registered Electronic Mail Services; Part 1: Testing conformance".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI EN 319 532-1 [3] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACC_REJ_EXP ACCeptanceREJectionEXPiry
CONS_ACC CONSignmentACCeptance
CONS_NOT CONSignmentNOTification
CONS_NOT_FAIL CONSignmentNOTificationFAILure
CONS_REJ CONSignmentREJection
CONT_CONS CONTentCONSignment
CONT_CONS_FAIL CONTentCONSignmentFAILure
CONT_HAND CONTentHANDover
CONT_HAND_FAIL CONTentHANDoverFAILure
ERDS Electronic Registered Delivery
EV_SET EVidence SET
IREMS Intermediate Registered Electronic Mail Service
ETSI
8 ETSI TS 119 534-2 V1.1.1 (2019-02)
NOT_F_ACC NOTificationForACCeptance
NOT_F_ACC_FAIL NOTificationForACCeptanceFAILure
REC_F_NERDS RECeivedFromNonERDS
REL_ACC RELayACCeptance
REL_FAIL RELayFAILure
REL_REJ RELayREJection
REL_T_NERDS RELayToNonERDS
REL_T_NERDS_FAIL RELayToNonERDSFAILure
REM Registered Electronic Mail
REMS Registered Electronic Mail Service
RREMS Recipient's Registered Electronic Mail Service
SCN_ID Scenario Identifier
SMIME Secure/Multipurpose Internet Mail Extensions
SREMS Sender's Registered Electronic Mail Service
SUB_ACC SUBmissionACCeptance
SUB_REJ SUBmissionREJection
4 Technical approach
4.1 Components of test cases and their identifiers
As it has been mentioned before the present document defines:
1) A test suite for supporting interoperability tests within the field of Registered Electronic Mail (REM
hereinafter) as specified in ETSI EN 319 532 parts 1 [3], 2 [4], 3 [5] and 4 [6].
2) A mechanism for documenting new test cases and expanding the aforementioned test suite.
The present document follows a layered approach for building the definition of the test cases in the test suite, which can
be summarized as follows:
1) Clause 5 defines a number of parameterized scenarios. A scenario consists of a number of entities, namely:
sender, one or more REMSs, and the entities at receiving side - one or more recipients and/or one or more
recipients' delegates -, which exchange different REM messages with time. Each scenario corresponds to one
of the three models presented in ETSI EN 319 532-1 [3]. This clause presents a template for defining one
scenario, in a way that resembles to some templates used for defining use cases scenarios in software
engineering.
This template:
- Includes the enumeration of all the REM messages exchanged by the participating entities. This list of
exchanged REM messages is one of the parameters of the scenario.
- Also includes a list of ERDS evidence sets, which, in the scenario, are incorporated in some REM
messages.
One scenario may be used for defining several test cases depending on:
- The specific components of each exchanged REM message (suppressing or adding an optional header, or
changing the value of a certain header field results in a different REM message and consequently a
different test case).
- The entities at receiving part (for instance, changing one recipient by one recipient's delegate, or two
recipients and one recipient's delegate results in a different the test case).
- A named set of additional requirements (for instance whether the original message contains or not
attachments, is signed, is encrypted, etc.).
- In negative test cases, i.e. test cases where the service failed in consigning or handing over the message
to one or more recipients, the reason(s) causing that failure.
ETSI
9 ETSI TS 119 534-2 V1.1.1 (2019-02)
This means that one test case corresponds to one scenario where all the exchanged REM messages have been
completely defined in terms of their components, all the participating entities have been established, and all the
additional requirements have also been defined. Taking the functional notation this can be expressed as follows:
TestCase#i = Scenario_id(, , identifier 2>, …, , , reasons>?
Where:
- is the identifier assigned to a certain set of entities at receiving side;
- is the identifier of a specific instantiation of the aforementioned REM
message, namely: REM payload, REM notification, REM Receipt, or REM dispatch, which are defined
in clauses 6.3, 6.4, 6.5 and 6.6 respectively.
- is the identifier of a named set of additional requirements.
Clause 7.2 defines a number of these named sets.
- ? is the reason(s) that caused that the service failed in consigning or handing over the
message to the recipient(s). It shall only appear in negative test cases.
2) Clauses 6.3, 6.4, 6.5 and 6.6 define specific instantiations of REM payloads, REM notifications, REM receipts
and REM dispatches respectively. Each type of REM message is composed by several MIME sections, with
their headers and bodies. One specific instantiation of a certain type of REM message is composed by one
specific combination of MIME sections. Each MIME section in turn is formed by one certain combination of
headers and has a specific value in its body. The present document defines a number of combinations of
MIME sections in clauses 6.2.2, 6.2.3, 6.2.4.3, 6.2.4.4, 6.2.5, 6.2.6, 6.2.7 and 6.2.8, and assigns to each one a
unique identifier. This allows to use again the functional notation, and define one instantiation of a certain type
of REM message as follows:
REM message instance = Sequence(, section identifier>, , html MIME section>, ?, identifier>*, *,)
Where ? indicates a cardinality 0 or 1 for the affected MIME section, and * indicates a cardinality of 0 or more for the
affected MIME sections.
3) Clauses 6.2.2, 6.2.3, 6.2.4.3, 6.2.4.4, 6.2.5, 6.2.6, 6.2.7 and 6.2.8 define specific instances for the outermost
MIME header, the signed data MIME header, the multipart/alternative free text MIME section, the
multipart/alternative html MIME section, original message MIME section, the extension MIME section, the
ERDS evidence MIME section, and the signature MIME section respectively. Each clause define different
instances of the aforementioned headers and sections and assigns them unique identifiers that are used for
defining specific instances of the different REM messages as shown above. Once this level is reached, the
specific test case is fully defined as: a scenario where fully defined, REM messages are exchanged between a
specific set participating entities, and where a specific set of additional requirements are imposed.
4.2 Adding new test cases to the test suite
The strategy followed for building the definitions of the test cases makes it easy to expand the test suite by
incorporation of new test cases.
For defining a new test case the following steps are required:
1) Identify the set of receiving entities. If none of the predefined set of entities at the receiving side is the one
required, define a new set as specified in clause 7.3. The sender is always present by default.
2) Define the REMSs that will participate in the test case.
3) If the set of participating REMSs is not equal to none of the scenarios already identified in the present
document, the new scenario will require to be defined in a new template.
ETSI
10 ETSI TS 119 534-2 V1.1.1 (2019-02)
4) Identify the sequence of actions performed by each actor and their order of occurrence and assign a new
unique identifier () to the scenario.
5) Identify all the REM messages generated by the actors as they go through the sequence of actions. For each
message:
a) Identify its MIME sections.
b) For each MIME section identified different than the ERDS MIME sections, check if its header fields
combination and the corresponding bodies have already been defined in the present document. If not, add
the required combination of header fields and body values to the repertoire of named combinations to the
section defining instances of the aforementioned MIME section as in the corresponding clauses
(clauses 6.2.2, 6.2.3, 6.2.4.3, 6.2.4.4, 6.2.6 or 6.2.8).
c) List all the REM messages exchanged as parameters of the scenario.
d) Identify the ERDS evidence format and the set of ERDS evidence for each REM message including them
and add the names of the ERDS evidence sets to the Var section of the template.
6) Identify and define any other additional requirement for completely define the test case. If the set of
requirements is different than all the sets already define, assign a name to it () and add
it to the repertoire of named sets of additional requirements in Table 23 (clause 7.2).
5 Scenarios
5.1 Introduction
The present clause defines a number of selected scenarios that will be used in clause 8.
Clause 5.3 defines scenarios where sender and recipient(s) are subscribed to the same REMS.
Clause 5.4 defines scenarios where the sender and the recipient(s) are subscribed to different REMSs and there are not
intermediate REMSs between them.
Clause 5.5 defines scenarios where sender is subscribed to a REMS and the recipient(s) is(are) not subscribed to the
same REMS and there are one or more intermediate REMSs.
Unless anything said against it, all the scenarios assume that there are N entities at the receiving side.
Unless anything said against it, all the ERDS evidences that can contain details of different entities at the receiving side
shall incorporate the details of the entire set of N entities at the receiving side.
Table 1 shows the template for defining one scenario.
ETSI
11 ETSI TS 119 534-2 V1.1.1 (2019-02)
Table 1: Template for the tabular definition of one scenario
Scenario id: Purpose
Parameter: _with_XML_SUB_REJ Var EV_SET#1 = {…, …}
1 that helps to fully specify the scenario. Their number depends
Named sets of ERDS evidence used in
on the specific scenario>
the definition of the scenario.
Parameter: Var EV_SET#2 = {… …}
Parameter: Var EV_SET#N = {… …}
Sequence of actions

# Sender REMS Receiving side
The sequence is composed of a number of numerated steps, when the actors perform certain actions as
shown below.
Some frequent actions: send original message, accept submission, reject submission, consign, generate
one ERDS evidence, generate one REM message, etc.
1 Sender sends original message
Rejects submission. Generates
XML_SUB_REJ ERDS evidence
Generates
_with_XML_SUB_REJ
Sends
_with_XML_SUB_REJ
Receives
_with_XML_SUB_REJ

Each scenario is assigned a unique identifier . The reasons why the scenario has been defined are shown in
column "Purpose".
The definition of each scenario requires that parties exchange a number of REM messages, which appear listed as
parameters in the rows immediately below the headers row. Its number depends on the specific scenario.
Below the list of parameters the table shows a sequence of actions performed by different involved entities, which
results in that a set of REM messages is generated and exchanged.
The definition of each scenario also can use a number of named ERDS evidence sets, which are listed in cells started
with Var. Each ERDS evidence set is given a name EV_SET#, being a non-negative integer number.
The involved entities are sender (or sender's delegate, the scenario definition does not make any distinction between
them), one or more REMSs, and the entities at the receiving side (for the same scenario there may be different sets of
entities, for instance one recipient, one recipient's delegate, one or more recipients, or one or more recipients and one or
more recipients' delegates).
Each step is assigned a positive integer number. The actions performed include: submission of messages, generation of
REM messages, generation of ERDS evidence, acceptance of REM messages, rejection of REM messages, consignment
of REM messages, retrieval of REM messages by entities at receiving side, failures, etc.
5.2 Abbreviations used in tables defining scenarios
The present clause shows some abbreviations (which have already been anticipated in clause 3.3 which have already
been anticipated in clause 3.3) used in the tables that define the scenarios.
Table 2 shows the abbreviations used for the different ERDS evidence.
ETSI
12 ETSI TS 119 534-2 V1.1.1 (2019-02)
Table 2: ERDS evidence abbreviations
ERDS Evidence name ERDS Evidence abbreviation
SubmissionAcceptance SUB_ACC
SubmissionRejection SUB_REJ
RelayAcceptance REL_ACC
RelayRejection REL_REJ
RelayFailure REL_FAIL
NotificationForAcceptance NOT_F_ACC
NotificationForAcceptanceFailure NOT_F_ACC_FAIL
ConsignmentAcceptance CONS_ACC
ConsignmentRejection CONS_REJ
AcceptanceRejectionExpiry ACC_REJ_EXP
ContentConsignment CONT_CONS
ContentConsignmentFailure CONT_CONS_FAIL
ConsignmentNotification CONS_NOT
ConsignmentNotificationFailure CONS_NOT_FAIL
ContentHandover CONT_HAND
ContentHandoverFailure CONT_HAND_FAIL
RelayToNonERDS REL_T_NERDS
RelayToNonERDSFailure REL_T_NERDS_FAIL
ReceivedFromNonERDS REC_F_NERDS

ETSI EN 319 522-1 [1] specify a XML format for ERDS evidence, but also allows that they are PDF documents. The
present document differentiates both cases using a prefix for the ERDS evidence abbreviations as follows:
• XML_ prefix indicates that the identified object is a XML ERDS evidence;
• PDF_ prefix that the identified object is a PDF ERDS evidence.
EXAMPLE: The abbreviation for the XML SubmissionAcceptance ERDS evidence will be XML_SUB_ACC.
The abbreviation for the PDF SubmissionAcceptance ERDS evidence will be PDF_SUB_ACC.
The tables defining the Scenarios use the following abbreviations for the different participating REMSs:
• SREMS stands for the REMS serving the sender, in the scenarios where it is different from the REMS serving
the entities at receiving side.
• RREMS stands for the REMS serving the entities at receiving side, in the scenarios where it is different from
the REMS serving the sender.
• IREMS stands for a REMS that directly serves neither the sender nor the recipient(s)/recipient's delegate, but
instead is an intermediate REMS that relays REM messages from SREMS to RREMS and from RREMS to
SREMS.
5.3 Black-box model scenarios
5.3.1 Introduction
This clause defines scenarios where the sender and the entities at the receiving side are subscribed to the same REMS
and consequently REM messages are not relayed between different REMSs.
Clause 5.3.2 defines scenarios where the REMS operates in Store and Forward style.
Clause 5.3.3 defines scenarios where the REMS operates in Store and Notify style.
5.3.2 Scenarios for Store and Forward style
Table 3 defines a number of scenarios for the case where sender and the entities at receiving side are subscribed to the
same REMS operating in Store and Forward style.
ETSI
13 ETSI TS 119 534-2 V1.1.1 (2019-02)
Table 3: Scenarios for intra-REMS operating in Store and Forward style (1/13)
Scenario id: REMS_SF#1 Purpose
Parameter: _with_XML_SUB_REJ The simplest scenario: the
Sequence of actions REMS rejects the original
message submitted by the
# Sender REMS Receiving side
sender because a unique
1 Sender sends original message
reason, and sends back a REM
Rejects submission. Generates SUB_REJ ERDS
receipt with the
evidence with details of the N recipients
SubmissionRejection ERDS
3 Generates _with_XML_SUB_REJ
evidence
4 Sends REMS receipt to the sender
5 Receives REMS receipt
NOTE 1: As it has been anticipated, negative scenarios like this one do not mention the reason for failure. This is a separated parameter for the test case definition in
clause 8.
Table 3a: Scenarios for intra-REMS operating in Store and Forward style (2/13)
Scenario id: REMS_SF#2 Purpose
Parameter: _with_XML_SUB_REJ Var EV_SET#1 = {2 XML_SUB_REJ } As before but now the REMS
rejects the original message
Sequence of actions
submitted by the sender
# Sender REMS Receiving side
because of one reason for M
1 Sender sends original message
entities at the receiving side and
Rejects submission. Generates 2 XML_SUB_REJ
because another reason for the
2 ERDS evidences. One of them with details of M
other N-M entities.
entities; the other with details of N-M entities
It generates two
Generates _with the
SubmissionRejection ERDS
2_aforementioned XML_SUB_REJ
evidences it and sends back a
4 Sends REMS receipt to the sender
REM receipt with these two
SubmissionRejection ERDS
5 Receives REMS receipt
evidences
ETSI
14 ETSI TS 119 534-2 V1.1.1 (2019-02)
Table 3b: Scenarios for intra-REMS operating in Store and Forward style (3/13)
Scenario id: REMS_SF#3 Purpose
Parameter: _with_XML_SUB_ACC Var EV_SET#1 = {XML_SUB_ACC , XML_CONT_CONS} The simplest successful
Parameter: _with_EV_SET#1 scenario: the REMS accepts the
submission of the original
Sequence of actions
message, generates as many
# Sender REMS Receiving side
REM dispatches as required by
1 Sender sends original message
the number of entities in the
Accepts submission. Generates XML_SUB_ACC
2  receiving side enclosing the
ERDS evidence
original message and the
Generates
SubmissionAcceptance ERDS
3 _with_XML_SUB_ACC for the N
evidence, and delivers them to
receiving entities
the receiving side. After that it
4 Consigns REM dispatch to receiving side
generates and sends back to the
Generates one XML_CONT_CONS ERDS _with_XML_SUB_AC
sender a REM receipt with one
evidence with details of the N recipients C consigned to receiving side
SubmissingAcceptance ERDS
6 Generates _with_EV_SET#1
evidence and one
7 Sends it back to sender
ContentConsignment ERDS
evidence. Each evidence
8 Receives _with_EV_SET#1
includes the details of all the
(N) entities at receiving side

ETSI
15 ETSI TS 119 534-2 V1.1.1 (2019-02)
Table 3c: Scenarios for intra-REMS operating in Store and Forward style (4/13)
Scenario id: REMS_SF#4 Purpose
Parameter: _with_XML_SUB_ACC Var EV_SET#1 = {XML_SUB_ACC , XML_CONT_CONS, As scenario REMS_SF#3 but
XML_CONT_CONS_FAIL} now one consignment fails
Parameter: _with_EV_SET#1
Sequence of actions
# Sender REMS Receiving side
1 Sender sends original message
Accepts submission. Generates XML_SUB_ACC
ERDS evidence
Generates
3 _with_XML_SUB_ACC for the N
receiving entities
4 Consigns REM dispatch to receiving side
Generates one XML_CONT_CONS ERDS N-1
evidence with details of the N-1 entities AND one _with_XML_SUB_AC
XML_CONT_CONS_FAIL with details of one entity C consigned to receiving side
1 fails
6 Generates _with_EV_SET#1
7 Sends it back to sender
8 Receives _with_EV_SET#1

ETSI
16 ETSI TS 119 534-2 V1.1.1 (2019-02)
Table 3d: Scenarios for intra-REMS operating in Store and Forward style (5/13)
Scenario id: REMS_SF#5 Purpose
Parameter: _with_XML_SUB_ACC Var EV_SET#1 = {XML_SUB_ACC , XML_CONT_CONS, 2 As scenario REMS_SF#3 but
XML_CONT_CONS_FAIL} now two consignments fail, and
each one for different reason,
Parameter: _with_EV_SET#1
which implies the generation of
Sequence of actions
two XML_CONT_CONS_FAIL
# Sender REMS Receiving side
ERDS evidences
1 Sender sends original message
Accepts submission. Generates XML_SUB_ACC
ERDS evidence
Generates
3 _with_XML_SUB_ACC for the N
receiving entit
...