|
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
---------------------- Page: 1 ----------------------
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:
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 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
---------------------- Page: 3 ----------------------
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
---------------------- Page: 4 ----------------------
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
---------------------- Page: 5 ----------------------
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
---------------------- Page: 6 ----------------------
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
---------------------- Page: 7 ----------------------
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
---------------------- Page: 8 ----------------------
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 =
...