ETSI TS 103 596-1 V1.1.1 (2021-05)

ETSI TS 103 596-1 V1.1.1 (2021-05)






TECHNICAL SPECIFICATION
Methods for Testing and Specification (MTS);
Test Specification for CoAP;
Part 1: Conformance Tests



---------------------- Page: 1 ----------------------
2 ETSI TS 103 596-1 V1.1.1 (2021-05)

Reference
DTS/MTS-TSTCoAP-1
Keywords
conformance, TSS&TP

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 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

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
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2021.
All rights reserved.

ETSI

---------------------- Page: 2 ----------------------
3 ETSI TS 103 596-1 V1.1.1 (2021-05)
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 and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Test Suite Structure . 7
4.0 Introduction . 7
4.1 Server as SUT . 8
4.2 Client as SUT . 8
4.3 TP naming convention . 8
4.4 TP structure . 9
5 Test Purposes for CoAP Server . 10
6 Test Purposes for CoAP Client . 64
Annex A (normative): CoAP Test Purposes (TPs) . 79
A.1 Introduction . 79
History . 80


ETSI

---------------------- Page: 3 ----------------------
4 ETSI TS 103 596-1 V1.1.1 (2021-05)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 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.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Methods for Testing and
Specification (MTS).
The present document is part 1 of a multi-part deliverable covering the Constrained Application Protocol (CoAP), as
identified below:
Part 1: "Conformance Tests";
Part 2: "Security Tests";
Part 3: "Performance Tests".
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.
Introduction
While the Internet of Things (IoT) is on the rise, the quality assurance of interconnected systems becomes an ever-
increasing challenge. Within the last years, many different IoT protocols came to the fore.
The present document provides a test specification, i.e. an overall test suite structure and catalogue of test purposes for
the Constrained Application Protocol (CoAP). It will be a reference base for both client-side test campaigns and server-
side test campaigns addressing the conformance issues.
ETSI

---------------------- Page: 4 ----------------------
5 ETSI TS 103 596-1 V1.1.1 (2021-05)
In the present document the conformance testing is presented. It provides a basis for interoperability testing and
performance testing. The latter is presented in ETSI TS 103 536-3 [i.3].

ETSI

---------------------- Page: 5 ----------------------
6 ETSI TS 103 596-1 V1.1.1 (2021-05)
1 Scope
The present document provides a test specification, i.e. an overall test suite structure and catalogue of test purposes for
the Constrained Application Protocol (CoAP). It will be a reference base for both client-side test campaigns and server-
side test campaigns addressing the conformance issues.
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] IETF RFC 7252: "The Constrained Application Protocol (CoAP)".
[2] ETSI ES 203 119-4: "Methods for Testing and Specification (MTS); The Test Description
Language (TDL); Part 4: Structured Test Objective Specification (Extension)".
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] ISO/IEC 9646-1: "Information technology -- Open Systems Interconnection -- Conformance
testing methodology and framework -- Part 1: General concepts".
[i.2] ETSI ES 202 951: "Methods for Testing and Specification (MTS); Model-Based Testing (MBT);
Requirements for Modelling Notations".
[i.3] ETSI TS 103 596-3: "Methods for Testing and Specification (MTS); Test Specification for CoAP;
Part 3: Performance Tests".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
conformance: extent to which an implementation of a standard satisfies the requirements expressed in that standard
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TS 103 596-1 V1.1.1 (2021-05)
conformance testing: process to verify to what extent the IUT conforms to the standard
content format: encoded format for converting a specific type of data to displayable information
NOTE: See IETF RFC 7252 [1].
implementation under test: implementation of one or more Open Systems Interconnection (OSI) protocols in an
adjacent user/provider relationship, being the part of a real open system, which is to be studied by testing
NOTE: See ISO/IEC 9646-1 [i.1].
proxy: server that acts as an intermediary for requests from clients seeking resources from other servers
system under test: real open system in which the implementation under test resides
NOTE: See ETSI ES 202 951 [i.2].
test purpose: non-formal high-level description of a test, mainly using text
test suite structure: document defining (hierarchical) grouping of test cases according to some rules
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
CoAP Constrained Application Protocol
ETAG Entity Tag
HTTP Hypertext Transfer Protocol
IUT Implementation Under Test
RST Reset
SD Service Discover
SUT System Under Test
TDL Test Description Language
TDL-TO Test Description Language - Test Objectives
TP Test Purpose
TSS Test Suite Structure
URI Uniform Resource Identifier
4 Test Suite Structure
4.0 Introduction
The following two clauses describe the TSS. In the first one a CoAP server as SUT is considered and in the latter, a
CoAP client as SUT is considered.
As the base CoAP IETF RFC 7252 [1] contain no explicit requirements for testing, neither provide concrete
conformance statements, the TPs were generated because of analysis of the mentioned RFC. The structure itself is
partly derived from the CoAP spec [1] but changed due to overlapping functions that cannot be tested separately.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TS 103 596-1 V1.1.1 (2021-05)
4.1 Server as SUT
1) Message format:
a) Support all defined method codes and understand regular and illegal or corrupted data along with them
2) Protocol features:
a) Separate/Piggybacked
b) Options
c) Content format
d) Error handling
3) Optional:
a) Proxying
4.2 Client as SUT
1) Message format:
a) Support all defined method codes and understand regular and illegal or corrupted data along with them
2) Protocol features:
a) Separate/Piggybacked
b) Options
c) Content format
d) Error handling
4.3 TP naming convention
TPs are numbered, starting at 001, within each main scope. The main scopes are organized according to the TSS. Some
TPs may not have a second level scope.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TS 103 596-1 V1.1.1 (2021-05)
Table 1: TP identifier naming convention scheme
Identifier: TP____<2nd_lvl_scope>*___

TP = Test Purpose Fixed to TP
= Protocol name Fixed to CoAP
= Type of IUT Client or Server
= Main scope Scope of the protocol (feature)
MessageFormat Mandatory Message Format
Separate  Separate Messages
Options  CoAP Messages with Options
Payload  CoAP Message with Payload
Proxy   Communication with a proxy
ServiceDiscovery CoAP Message concerning SD
<2nd_lvl_scope = Second level scope Header  CoAP Header fields
>* Response  CoAP response
* = Field of the scope Field of the given scope to be tested
* = Value of the field Value of the given field to be tested
= Sequential number Optional, from 001 to 999

*optional

4.4 TP structure
Each TP has been written in TDL-TO and thus in a structured manner which is consistent with all other TPs. The
intention of this is to make the TPs more formal. In addition, a more readable format is provided by generating tables
out of the TDL-TO format. The defined structure, that has been used, is illustrated in table 2. This table should be read
in conjunction with any TP, i.e. please use a TP as an example to facilitate the full comprehension of table 2. All
structures are defined formally in the TDL specification ETSI ES 203 119-4 [2].
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TS 103 596-1 V1.1.1 (2021-05)
Table 2: Structure of a single TP
TP part Text Example
Header  see table 1
 "The IUT is responding on a correctly set …"
IETF RFC 7252
PIC_Server
Initial Free text description of the condition that the IUT … the IUT is in the initial state …
condition has reached before the test purpose applies.
(optional)
Start point Describes the full logic of the test purpose. Expected behaviour
Includes trigger and expected behaviour of the ensure that { … }
IUT.
Trigger One or more actions that trigger an expected when {
response of the IUT. Mostly a set of different  the IUT entity receives a request message
messages the IUT receives.  containing version indicating value 1 …
}
Expected Describes the response that the IUT sends after then {
behaviour receiving a certain (set of) messages. This  the IUT entity sends a response message
response describes the pass criteria  containing version indicating value 1 …
}

5 Test Purposes for CoAP Server
TP Id TP_CoAP_MessageFormat_Header_Version_001
Test Objective The IUT is responding on a correctly set version number.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 0, //Confirmable
        token_length indicating value 0,
        code indicating value 0.00, //Empty Message
        msg_id corresponding to MSG_ID1;
  }
  then {
      the IUT sends a response message containing
        version indicating value 1,
        msg_type indicating value 3, //Reset
        token_length indicating value 0,
        code indicating value 0.00, //Empty Message
        msg_id corresponding to MSG_ID1;
      or the client times_out
  }
}
Final Conditions


ETSI

---------------------- Page: 10 ----------------------
11 ETSI TS 103 596-1 V1.1.1 (2021-05)
TP Id TP_CoAP_MessageFormat_Header_Version_002
Test Objective The IUT silently ignores an incorrectly set version number.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 3, //reserved
        msg_type indicating value 0, //Confirmable
        token_length indicating value 0,
        code indicating value 0.00, //Empty Message
        msg_id corresponding to MSG_ID1;
  }
  then {
      the client times_out
  }
}
Final Conditions


TP Id TP_CoAP_MessageFormat_Header_Type_CON_001
Test Objective The IUT is acknowledging on a Confirmable message correctly.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 0, //Confirmable
        token_length indicating value 0,
        code indicating value 0.01, //GET request
        msg_id corresponding to MSG_ID1;
  }
  then {
      the IUT sends a response message containing
        version indicating value 1,
        msg_type indicating value 2, //Acknowledge, from IETF RFC 7252 section 4.2 (a)
        token_length indicating value 0,
        code indicating value 2.05, //Success (Content)
        msg_id corresponding to MSG_ID1;
  }
}
Final Conditions


ETSI

---------------------- Page: 11 ----------------------
12 ETSI TS 103 596-1 V1.1.1 (2021-05)
TP Id TP_CoAP_MessageFormat_Header_Type_CON_002
Test Objective The IUT is rejecting a Confirmable message that is carrying a response.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 0, //Confirmable
        token_length indicating value 0,
        code indicating value 2.03, //Valid, response code
        msg_id corresponding to MSG_ID1;
  }
  then {
      the IUT sends a response message containing
        version indicating value 1,
        msg_type indicating value 3, //Reset
        token_length indicating value 0,
        code indicating value 0.00, //Empty Message
        msg_id corresponding to MSG_ID1;
      or the client times_out
  }
}
Final Conditions


TP Id TP_CoAP_MessageFormat_Header_Type_CON_003
Test Objective The IUT is rejecting a Confirmable message that lacks context to process the message properly.
The message carries a reserved class.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 0, //Confirmable
        token_length indicating value 0,
        code indicating value 1.00, //reserved
        msg_id corresponding to MSG_ID1;
  }
  then {
      the IUT sends a response message containing
        version indicating value 1,
        msg_type indicating value 3, //Reset
        token_length indicating value 0,
        code indicating value 0.00, //Empty Message
        msg_id corresponding to MSG_ID1;
      or the client times_out
  }
}
Final Conditions


ETSI

---------------------- Page: 12 ----------------------
13 ETSI TS 103 596-1 V1.1.1 (2021-05)
TP Id TP_CoAP_MessageFormat_Header_Type_NON_001
Test Objective The IUT is acknowledging on a Non-confirmable message correctly.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 1, //Non-confirmable
        token_length indicating value 0,
        code indicating value 0.01, //GET request
        msg_id corresponding to MSG_ID1;
  }
  then {
      the IUT sends a response message containing
        version indicating value 1,
        msg_type indicating value 1, //Non-confirmable
        token_length indicating value 0,
        code indicating value 2.05, //Success (Content)
        msg_id corresponding to MSG_ID2;
  }
}
Final Conditions


TP Id TP_CoAP_MessageFormat_Header_Type_NON_002
Test Objective The IUT is rejecting a Non-confirmable message that is Empty.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 1, //Non-confirmable
        token_length indicating value 0,
        code indicating value 0.00, //Empty Message
        msg_id corresponding to MSG_ID1;
  }
  then {
      the client times_out
  }
}
Final Conditions


ETSI

---------------------- Page: 13 ----------------------
14 ETSI TS 103 596-1 V1.1.1 (2021-05)
TP Id TP_CoAP_MessageFormat_Header_Type_NON_003
Test Objective The IUT is rejecting a Non-confirmable message that is carrying a response.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 1, //Non-confirmable
        token_length indicating value 0,
        code indicating value 2.03, //Success (Valid)
        msg_id corresponding to MSG_ID1;
  }
  then {
      the client times_out
  }
}
Final Conditions


TP Id TP_CoAP_MessageFormat_Header_Type_NON_004
Test Objective The IUT is rejecting a NON-confirmable message that lacks context to process the message
properly. The message carries a reserved class.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 0, //Confirmable
        token_length indicating value 0,
        code indicating value 6.00, //reserved
        msg_id corresponding to MSG_ID1;
  }
  then {
      the client times_out
  }
}
Final Conditions


ETSI

---------------------- Page: 14 ----------------------
15 ETSI TS 103 596-1 V1.1.1 (2021-05)
TP Id TP_CoAP_MessageFormat_Header_Type_ACK_001
Test Objective The IUT is rejecting an Acknowledgement message that is carrying a request.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 2, //Acknowledgement
        token_length indicating value 0,
        code indicating value 0.02, //POST request
        msg_id corresponding to MSG_ID1;
  }
  then {
      the client times_out
  }
}
Final Conditions


TP Id TP_CoAP_MessageFormat_Header_Type_ACK_002
Test Objective The IUT is rejecting an Acknowledgement message that carries a reserved class.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 2, //Acknowledgement
        token_length indicating value 0,
        code indicating value 7.00, //reserved
        msg_id corresponding to MSG_ID1;
  }
  then {
      the client times_out
  }
}
Final Conditions


ETSI

---------------------- Page: 15 ----------------------
16 ETSI TS 103 596-1 V1.1.1 (2021-05)
TP Id TP_CoAP_MessageFormat_Header_Type_RST_001
Test Objective The IUT is rejecting a Reset message that is not Empty.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 3, //Reset
        token_length indicating value 0,
        code indicating value 0.02, //PUT request
        msg_id corresponding to MSG_ID1;
  }
  then {
      the client times_out
  }
}
Final Conditions


TP Id TP_CoAP_MessageFormat_Header_TokenLength_001
Test Objective The IUT is responding on a valid token length correctly.
Reference IETF RFC 7252 [1]
PICS Selection PIC_Server
Initial Conditions

Expected Behaviour
ensure that {
  when {
      the IUT receives a request message containing
        version indicating value 1,
        msg_type indicating value 0, //Confirmable
        token_length indicating value 0,
        code indicating value 0.01, //GET request
        msg_id corresponding to MSG_ID1,
        token corresponding to TOKEN;
  }
  then {
      the IUT sends a response message containing
        version indicating value 1,
        msg_type indicating val
...