|
TECHNICAL SPECIFICATION
Electronic Signatures and Infrastructures (ESI);
Testing Conformance and Interoperability of
Electronic Registered Delivery Services;
Part 2: Test suites for interoperability testing of
Electronic Registered Delivery Service Providers
---------------------- Page: 1 ----------------------
2 ETSI TS 119 524-2 V1.1.1 (2019-02)
Reference
DTS/ESI-0019524-2
Keywords
electronic registered delivery, interoperability,
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:
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
If you find errors in the present document, please send your comment to one of the following services:
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
---------------------- Page: 2 ----------------------
3 ETSI TS 119 524-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 without notification for acceptance . 12
5.3.3 Scenarios with notification for acceptance . 20
5.4 Scenarios for 4-corner model . 26
5.4.1 Introduction. 26
5.4.2 Scenarios where RERDS does not use notification for acceptance . 26
5.4.3 Scenarios where RERDS uses notification for acceptance . 34
5.5 Scenarios for extended model . 43
5.5.1 Introduction. 43
5.5.2 Scenarios where RERDS does not use notification for acceptance . 43
5.5.3 Scenarios where RERDS uses notification for acceptance . 52
6 ERD Messages instances . 60
6.1 Introduction and technical approach. 60
6.2 Combinations of fields for headers in ERD envelopes . 60
6.2.1 Introduction. 60
6.2.2 Combinations of AS4 metadata profiled in ETSI EN 319 522-4 . 60
6.2.3 Combinations of components of relay metadata . 61
6.2.4 Combinations of AS4 metadata profiled and relay metadata . 65
6.3 Instances of ERD payload . 66
6.4 Instances of ERDS receipts . 66
6.5 Instances of ERD dispatch. 66
7 Other named sets . 67
7.1 Named sets of participating ERDSs . 67
7.2 Named sets of additional requirements . 67
7.3 Named sets of entities in receiving side . 67
8 Test cases definition . 67
8.1 Introduction . 67
8.1.1 General . 67
8.1.2 Notation for black box model scenarios . 68
8.1.3 Notation for 4 corner and extended models scenarios . 68
8.1.4 Reasons for Failures. 70
8.2 Test cases for black box model . 70
8.3 Test cases for 4-cornel and extended models . 70
8.3.1 General . 70
ETSI
---------------------- Page: 3 ----------------------
4 ETSI TS 119 524-2 V1.1.1 (2019-02)
8.3.2 Rules for parametrizing ERD dispatches . 70
8.3.3 Rules for parametrizing ERD payloads . 71
8.3.4 Rules for parametrizing ERDS receipts . 71
8.3.5 Rules for parametrizing entities at receiving side . 71
8.3.6 Rules for parametrizing failure reasons . 71
8.3.7 Rules for parametrizing additional requirements . 71
Annex A (informative): Bibliography . 72
History . 73
ETSI
---------------------- Page: 4 ----------------------
5 ETSI TS 119 524-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
---------------------- Page: 5 ----------------------
6 ETSI TS 119 524-2 V1.1.1 (2019-02)
1 Scope
The present document defines:
1) A test suite for supporting interoperability tests within the field of Electronic Registered Delivery Services
(ERD services or ERDS hereinafter) as specified in ETSI EN 319 522 parts 1 [1], 2 [2], 3 [3] and 4 [4], [5] and
[6]. The test suite defines test cases for the following environments:
- Environments that correspond to the basic model as defined in ETSI EN 319 522-1 [1] where sender and
all the entities at receiving side are subscribed to the same ERDS.
- Environments that correspond to the 4-corner model as defined in ETSI EN 319 522-1 [1] where sender
is subscribed to one ERDS and the entities at receiving side are subscribed to another one, and no
intermediate ERDS is required for relaying ERD messages between them.
- Environments that correspond to the extended model as defined in ETSI EN 319 522-1 [1] where sender
is subscribed to one ERDS and the entities at receiving side are subscribed to another one, and
intermediate ERDSs are required for relaying ERD messages between them.
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 522-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 3: Formats".
[4] ETSI EN 319 522-4-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 1: Message delivery bindings".
[5] ETSI EN 319 522-4-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 2: Evidence and identification bindings".
[6] ETSI EN 319 522-4-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 3: Capability/requirements bindings".
[7] ETSI EN 319 532-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 3: Formats".
[8] OASIS Standard (January 2013): "AS4 Profile of ebMS 3.0 Version 1.0".
ETSI
---------------------- Page: 6 ----------------------
7 ETSI TS 119 524-2 V1.1.1 (2019-02)
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 524-1: "Electronic Signatures and Infrastructures (ESI); Testing Conformance and
Interoperability of Electronic Registered Delivery Services; Part 1: Testing conformance".
[i.2] OASIS Standard (October 2007): "ebXML Messaging Services Version 3.0: Part 1, Core
Features".
NOTE: Available at http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.pdf.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI EN 319 522-1 [1] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACC_REJ_EXP ACCeptance REJection EXPiry
AS4 Applicability Statement 4
CONS_ACC CONSignment ACCeptance
CONS_NOT CONSignment NOTification
CONS_NOT_FAIL CONSignment NOTification FAILure
CONS_REJ CONSignment REJection
CONT_CONS CONTent CONSignment
CONT_CONS_FAIL CONTent CONSignment FAILure
CONT_HAND CONTent HANDover
CONT_HAND_FAIL CONTent HANDover FAILure
ebMS ebXML Messaging Services
ebXML Electronic Business using eXtensible Markup Language
ERD Electronic Registered Delivery
ERDS Electronic Registered Delivery Service
EV_SET Evidence - SET
IERDS Intermediate Electronic Registered Delivery Service
NOT_F_ACC NOTification For ACCceptance
OASIS Organization for the Advancement of Structured Information Standards
REC_F_NERDS RECeived From Non ERDS
REL_ACC RELay ACCeptance
REL_FAIL RELay FAILure
REL_REJ RELay REJection
REL_T_NERDS RELay To Non ERDS
REL_T_NERDS_FAIL RELay To Non ERDS FAILure
ETSI
---------------------- Page: 7 ----------------------
8 ETSI TS 119 524-2 V1.1.1 (2019-02)
REM Registered Electronic Mail
REMS Registered Electronic Mail Service
RERDS Recipient's Electronic Registered Delivery Service
SCN_ID Scenario IDentifier
SERDS Sender's Electronic Registered Delivery Service
SUB_ACC SUBmission ACCeptance
SUB_REJ SUBmission REJection
URI Universal Resource Identifier
XML eXtensible Mark-up Language
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 Electronic Registered Delivery (ERD
hereinafter) as specified in as specified in ETSI EN 319 522 parts 1 [1], 2 [2], 3 [3] and 4 [4], [5] and [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 ERDSs, and the entities at receiving side (one or more recipients and/or one or more
recipients' delegates), which exchange different ERD messages with time. Each scenario corresponds to one of
the three models presented in ETSI EN 319 522-1 [1]. 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 the original message and all the ERD messages exchanged by the
participating entities. This list of exchanged ERD 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 ERD
messages.
One scenario may be used for defining several test cases depending on:
- The specific components of each exchanged ERD message (suppressing or adding an optional metadata
component, or changing the value of a certain metadata component results in a different ERD 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 details of the original message, like whether it
contains or not attachments, is signed, is encrypted, etc.).
This means that one test case corresponds to one scenario where all the exchanged ERD 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(,, , details>, …, , Where:
- is the identifier assigned to a certain set of entities at receiving side;
ETSI
---------------------- Page: 8 ----------------------
9 ETSI TS 119 524-2 V1.1.1 (2019-02)
- is the identifier of a specific instantiation of the aforementioned message, defined
in clauses 6.3, 6.4 and 6.5. These clauses define specific instantiations of ERD payloads, ERD receipts
and ERD dispatches respectively.
- is the identifier of a named set of additional requirements.
Clause 7.2 defines a number of these named sets.
2) Clauses 6.3, 6.4 and 6.5 define specific instantiations of ERD payloads, ERD receipts and ERD dispatches
respectively. Each type of ERD message is composed by several components, with their metadata components
and payloads as specified in ETSI EN 319 522-4-1 [4] and ETSI EN 319 522-4-2 [5]. The present document
defines a number of combinations of metadata components in clauses 6.2.2 and 6.2.3, 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 ERD message as follows:
ERD message instance = Sequence(Metadata(, for ERDS relay metadata combination details>) * Evidence>*)
Where '*' stands for 0 or more occurrences of the payload.
NOTE: The payloads for user content and for ERDS evidence can be present at certain types of ERD messages
but are forbidden in other types.
3) Clauses 6.2.2 and 6.2.3 define named combinations of metadata components defined in OASIS: "AS4 Profile
of ebMS 3.0 Version 1.0" [8] and profiled in ETSI EN 319 522-4-1 [4] and ETSI EN 319 522-4-2 [5], and the
relay metadata components defined in ETSI EN 319 522-3 [3] respectively. Each clause define different
instances of the aforementioned components and assigns them unique identifiers that are used for defining
specific instances of the different ERD messages as shown above. Once this level is reached, the specific test
case is fully defined as: a scenario where fully defined, ERD 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, assign a name to this set () and incorporate it to the repertoire of
named sets as specified in clause 7.3). The sender is always present by default.
2) Define the ERDSs that will participate in the test case.
3) If the set of participating ERDSs 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.
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 ERD messages generated by the actors as they go through the sequence of actions. For each
message:
a) Identify its ebMS payloads, e.g. the parts of the user content or XML document with relay meta-data.
b) Check if the combinations of metadata components have already been defined in the present document.
If not, add the required combination of metadata components to the repertoire of named combinations to
the corresponding clause (clause 6.2.2 or 6.2.3).
c) List all the ERD messages exchanged as parameters of the scenario.
d) Identify the ERDS evidence format and the set of ERDS evidence for each ERD message including them
and add the names of the ERDS evidence sets to the Var section of the template.
ETSI
---------------------- Page: 9 ----------------------
10 ETSI TS 119 524-2 V1.1.1 (2019-02)
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 12 (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 ERDS (black-box model
described in ETSI EN 319 522-1 [1]).
Clause 5.4 defines scenarios where the sender and the recipient(s) are subscribed to different ERDSs and there are not
intermediate ERDSs between them (4-corner model described in ETSI EN 319 522-1 [1]).
Clause 5.5 defines scenarios where sender is subscribed to a ERDS and the recipient(s) is(are) not subscribed to the
same ERDS and there are one or more intermediate ERDSs (extended model described in ETSI EN 319 522-1 [1]).
Figure 1 of clause 4 of ETSI EN 319 522-2 [2] shows three structures being exchanged between ERD-UAs and ERDSs,
namely:
1) The structure {submission metadata, user content}, which receives the name of original message in Table 1 of
clause 4 of ETSI EN 319 522-2 [2].
2) The structure {ERDS handover metadata, ERDS evidence} for allowing access to ERDS evidences to users.
3) The structure {ERDS handover metadata, user content, ERDS evidence} for allowing the R-ERDS the
submission of the user content (and optionally ERDS evidences) to the recipient.
Because of that the following decisions have been adopted for building the scenarios:
1) Neither S-ERDS nor R-ERDS will submit {ERDS handover metadata, ERDS evidence} structures to their
users, except when the ERDS evidence is an evidence of some kind of relevant rejection by the ERDS (see the
first scenario, for instance). Identical scenarios including the submission of such structures can be easily
defined and used in interoperability test events.
2) The scenarios will show the R-ERDS submitting {ERDS handover metadata, user content, ERDS evidence} or
{ERDS handover metadata, user content} structures to the receiving side.
3) The acronym hndvMet is used for ERDS handover metadata.
Table 1 shows the template for defining one scenario.
ETSI
---------------------- Page: 10 ----------------------
11 ETSI TS 119 524-2 V1.1.1 (2019-02)
Table 1: Template for the tabular definition of one scenario
Scenario id: Purpose
Parameter: _with_XML_SUB_REJ 1 that helps to fully the scenario. Their number depends on the Named sets of ERDS evidence used in
specific scenario> the definition of the scenario.
Parameter: Var SET_EV#2 = {… …}
Parameter: Var SET_EV#N = {… …}
Sequence of actions
# Sender ERDS Receiving side
The sequence is composed of
...