Interoperability Test Description
Identifier: TD_COAP_LINK_01
Objective: Access to well-known interface for resource discovery
Configuration: CoAP_CFG_BASIC
References: [LINK]
Pre-test conditions:
  • Client and server supports CoRE Link Format
  • Server supports /.well-known/core resource and the CoRE Link Format
Test Sequence: Step Type Description
1 Stimulus Client is requested to retrieve Server’s list of resource
2 Check Client sends a GET request to Server for /.well-known/core resource
3 Check
  • Server sends response containing:
  • Content-format option indicating 40 (application/link-format)
  • Code indicating 2.05 (Content)
  • Payload indicating all the links available on Server
4 Verify Client displays the list of resources available on Server
Interoperability Test Description
Identifier: TD_COAP_LINK_02
Objective: Use filtered requests for limiting discovery results
Configuration: CoAP_CFG_BASIC
References: [LINK] 4.1
Pre-test conditions:
  • Client supports CoRE Link Format
  • Server supports CoRE Link Format
  • Server offers different types of resources (Type1, Type2, ...; see Note)
Test Sequence: Step Type Description
1 Stimulus Client is requested to retrieve Server’s list of resource of a specific type Type1
2 Check Client sends a GET request to Server for /.well-known/core resource containing URI-Query indicating “rt=Type1”
3 Check
  • Server sends response containing:
  • Content- format option indicating 40 (application/link-format) Payload indicating only the links of type Type1 available on Server
4 Verify Client displays the list of resources of type Type1 available on Server
Notes: Type1, Type2, ... refer to real resource types available on Server and shall be extracted from Server’s /.well-known/core resource
Interoperability Test Description
Identifier: TD_COAP_LINK_03
Objective: Handle empty prefix value strings
Configuration: CoAP_CFG_BASIC
References: [LINK] 4.1 §2
Pre-test conditions:
  • Client supports Core Link Format
  • Server supports Core Link Format
  • Server offers different types of resources (Type1, Type2, ...; see Note)
  • Server offers resources with no type (i.e. no rt attribute)
Test Sequence: Step Type Description
1 Stimulus Client is requested to retrieve Server’s list of resources matching an rt empty value
2 Check Client sends a GET request to Server for /.well-known/core resource containing URI-Query indicating rt=“*”
3 Check
  • Server sends response containing:
  • Content-format option indicating 40 (application/link-format)
  • Payload indicating only the links having an rt attribute
4 Verify Client displays the list of resources with rt attribute available on Server
Notes: Type1, Type2, ... refer to real resource types available on Server and shall be extracted from Server’s /.well-known/core resource
Interoperability Test Description
Identifier: TD_COAP_LINK_04
Objective: Filter discovery results in presence of multiple rt attributes
Configuration: CoAP_CFG_BASIC
References: [LINK] 3.1, 4.1 §2
Pre-test conditions:
  • Client supports Core Link Format
  • Server supports Core Link Format
  • Server offers 4 groups of resources:
    • Resources with rt=“Type1 Type2”
    • Resources with rt=“Type2 Type3”
    • Resources with rt=“Type1 Type3”
    • Resources with rt=“”
Test Sequence: Step Type Description
1 Stimulus Client is requested to retrieve Server’s list of resources of a specific type Type2
2 Check Client sends a GET request to Server for /.well-known/core resource containing URI-Query indicating rt=“Type2”
3 Check
  • Server sends response containing:
  • Content-format option indicating 40 (application/link-format)
  • Payload indicating only the links of groups 1 and 2
4 Verify Client displays the list of resources of type Type2 available on Server
Interoperability Test Description
Identifier: TD_COAP_LINK_05
Objective: Filter discovery results using if attribute and prefix value strings
Configuration: CoAP_CFG_BASIC
References: [LINK] 3.2, 4.1 §5
Pre-test conditions:
  • Client supports Core Link Format
  • Server supports Core Link Format
  • Server offers 4 groups of resources:
    • Resources with if=“If1”
    • Resources with if=“If2”
    • Resources with if=“foo”
    • Resources with no if attribute
Test Sequence: Step Type Description
1 Stimulus Client is requested to retrieve Server’s list of resources matching the interface description pattern “If*”
2 Check Client sends a GET request to Server for /.well-known/core resource containing URI-Query indicating if=“If*”
3 Check
  • Server sends response containing:
  • Content-format option indicating 40 (application/link-format)
  • Payload indicating only the links of groups 1 and 2
4 Verify Client displays the retrieved list of resources
Interoperability Test Description
Identifier: TD_COAP_LINK_06
Objective: Filter discovery results using sz attribute and prefix value strings
Configuration: CoAP_CFG_BASIC
References: [LINK] 3.3, 4.1 §5
Pre-test conditions:
  • Client supports Core Link Format
  • Server supports Core Link Format
  • Server offers resource with sz attribute
  • Server offers resources with no sz attribute
Test Sequence: Step Type Description
1 Stimulus Client is requested to retrieve Server’s list of resources having a sz attribute
2 Check Client sends a GET request to Server for /.well-known/core resource containing URI-Query indicating sz=“*”
3 Check
  • Server sends response containing:
  • Content-format option indicating 40 (application/link-format)
  • Payload indicating only the links having a sz attribute
4 Verify Client displays the retrieved list of resources
Interoperability Test Description
Identifier: TD_COAP_LINK_07
Objective: Filter discovery results using href attribute and complete value strings
Configuration: CoAP_CFG_BASIC
References: [LINK] 4.1
Pre-test conditions:
  • Client supports Core Link Format
  • Server supports Core Link Format
  • Server offers resources /link1 /link2 and /link3
Test Sequence: Step Type Description
1 Stimulus Client is requested to retrieve the link-value anchored at /link1
2 Check Client sends a GET request to Server for /.well-known/core resource containing URI-Query indicating href=“/link1”
3 Check
  • Server sends response containing:
  • Content-format option indicating 40 (application/link-format)
  • Payload indicating only the link for /link1
4 Verify Client displays the retrieved list of resources
Interoperability Test Description
Identifier: TD_COAP_LINK_08
Objective: Filter discovery results using href attribute and prefix value strings
Configuration: CoAP_CFG_BASIC
References: [LINK] 4.1
Pre-test conditions:
  • Client supports Core Link Format
  • Server supports Core Link Format
  • Server offers resources /link1 /link2 and /link3
  • Server offers resource /test
Test Sequence: Step Type Description
1 Stimulus Client is requested to retrieve the link-value anchored at /link*
2 Check Client sends a GET request to Server for /.well-known/core resource containing URI-Query indicating href=“/link*”
3 Check
  • Server sends response containing:
  • Content-format option indicating 40 (application/link-format)
  • Payload indicating only the link matching /link*
4 Verify Client displays the retrieved list of resources
Interoperability Test Description
Identifier: TD_COAP_LINK_09
Objective: Arrange link descriptions hierarchically
Configuration: CoAP_CFG_BASIC
References: [LINK] 5 §4
Pre-test conditions:
  • Client supports Core Link Format
  • Server supports Core Link Format
  • Server offers an entry located at /path with ct=40
  • Server offers sub-resources /path/sub1, /path/sub2, … (see Note)
Test Sequence: Step Type Description
1 Stimulus Client is requested to retrieve one of the sub-resources
2 Check Client sends a GET request to Server for /.well-known/core resource
3 Check
  • Server sends response containing:
  • Content-format option indicating 40 (application/link-format) Payload indicating the link description for /path
4 Check Client sends a GET request for /path to Server
5 Check
  • Server sends response containing:
  • Content-format option indicating 40 (application/link-format) Payload indicating the link description for /path/sub1, /path/sub2, …
6 Check Client sends a GET request for /path/sub1
7 Check
  • Server sends 2.05 (Content) response.
  • Payload contains /path/sub1
8 Verify Client displays the retrieved sub-resource.
Notes: /path/sub1, /path/sub2, … refer to real resources available on Server and shall be extracted from Server’s /.well-known/core resource