scope:

The present document defines a number of test suites for supporting interoperability tests within the field of Registered Electronic Mail as specified in TS 102 640 parts 1 to 6 [i.1], [i.2], [i.3], [i.4], [i.5] and [i.6].

A layering approach has been adopted for defining the test suite as described below:

• First a number of tests cases on evidences are defined so that entities testing interoperability may concentrate in identifying potential problems caused only by evidences. These tests do not depend on the type of format and transport binding expected (i.e. they are common to REM-MDs using S/MIME on SMTP and to REM-MDs using SOAP on HTTP).

• Secondly, a number of tests cases have been defined for testing interoperability regarding the REM-MD Envelope format and contents. Some of these test cases (specifically those that include an evidence set within the REM-MD Envelope), are built on already defined test cases on individual evidence. It has to be mentioned that two sets of test cases are defined at this layer: one for REM-MDs using S/MIME on SMTP as specified in TS 102 640-2 [i.2], and another for REM-MDs that use SOAP on HTTP binding as specified in TS 102 640 SOAP binding profile.

• Finally, a number of tests cases have been defined on complete flows of REM Objects so that entities testing interoperability may check several complete flows, including successful and unsuccessful by (well defined reasons) cycles.

For each of the three layers, both positive and negative test cases have been defined.

The present document defines interoperability tests for covering the following scenarios:

1) Scenarios where both sender and recipient are subscribed to the same REM-MD, be it operating under Store and Forward or Store and Notify mode of operation, and be it using S/MIME on SMTP or SOAP on HTTP.

2) Scenarios where sender and recipient are subscribed to a different REM-MD. This set assumes that both REM-MD use the same format and transport mechanisms (i.e. both use S/MIME on SMTP or SOAP on HTTP). As for the style of operation, this set includes test cases for scenarios where both REM-MDs operate under Store and Forward; test cases for scenarios where the sender's REM-MD operates under Store and Notify; and test cases for scenarios where the recipient's REM-MD operates under Store and Notify.

3) Scenarios where sender and recipient are subscribed one to a REM-MD as specified in TS 102 640 [i.1] to [i.6] and the other is subscribed to a UPU's Designated Operator. This set includes test cases for the REM-MD/ UPU gateway as specified in TS 102 640 [i.1] to [i.6] REM-MD UPU Interoperability Profile.

Readers of the present document are entirely free to select the subset of test cases that best suits their purposes and their convenience. In no way they should infer that they are required to test all the test cases specified in the present document.

Additionally, readers of the present document are noticed that for the test cases on complete flows of REM objects, certain decisions were made on the inclusion or not of certain objects within one REM-MD Envelope, as the TS 102 640 [i.1] to [i.6] does provide certain degree of freedom for doing that. They should, in consequence, feel free to alter the definitions of the test cases as best suits their purposes and their convenience as long as these changes do not lead to situations that are not compliant with the TS 102 640 specifications [i.1] to [i.6].

Clause 4 of the present document defines test cases on all the different types of evidence specified in TS 102 640-2 [i.2].

Clause 5 defines the test cases for testing REM-MD envelope formats and contents. Two sets of test cases are defined: one for entities using S/MIME on SMTP (clause 5.1) and other for entities using SOAP on HTTP (clause 5.2).

Clause 6 defines test cases for testing signatures generated by REM-MD.

Clause 7 defines test cases for testing complete flows of REM objects.

Clause 8 defines test cases for testing seamless exchange of messages and evidence between subscribers of REM-MDs and subscribers of UPU's Designated Operator (DO henceforth).