CoAP Discovery Workbench

Animate RFC 6690 /.well-known/core discovery, query filters, CoRE Link Format parsing, observable hints, and Resource Directory lookup.

Interactive CoAP discovery workbench for learning /.well-known/core requests, CoRE Link Format attributes, query filtering by rt/if/obs, Resource Directory lookup, and safe interpretation of discovered IoT resources.

CoAP RFC 6690 Link Format Discovery

CoAP Discovery Workbench

Watch a client ask a constrained endpoint what resources it exposes, then inspect how the compact CoRE Link Format turns into usable sensor, actuator, and service choices. Use the scenarios to compare direct endpoint discovery, query filters, observable-resource hints, Resource Directory lookup, and protected inventory.

Discovery target Endpoint /.well-known/core

Filter none

Links returned 6 of 6

Result 2.05 Content

Discovery flow

A client sends GET /.well-known/core, receives application/link-format, and parses each link into resource choices.

Step 1 of 5

CoRE Link Format response Content-Format 40

Request path /.well-known/core

The well-known discovery resource is the normal entry point for hosted links.

Link selection All advertised links

The server decides what links to expose and how to organize them.

Parser result rt, if, ct, obs, sz

Attributes describe target resources, not the discovery resource itself.

Next action GET selected resource

Discovery gives the URI and hints; normal CoAP requests still retrieve values.

Scenarios

Step through the packet path, parser output, and learner diagnosis for each discovery case.

Catalog size

6 resources

Filter strictness

normal

Method GET URI /.well-known/core Query none Accept 40

Packet and option inspector

Map the learner-visible URI to the CoAP request options.

Request

Parsed resources

Click a parsed card to inspect its link-format attributes.

6 links

Event trace

Follow the exact decision points from request construction to application choice.

Trace

Beginner ramp

These three ideas are enough to start reading a discovery response.

The URI is the starting point

A client normally asks GET /.well-known/core on a known endpoint. The response is not the sensor value; it is a compact catalog of resource links.

Attributes are hints

rt says what a resource is, if says how it behaves, ct lists possible representation formats, and obs hints that Observe may be useful.

Discovery is not authorization

Finding a URI does not prove a client may use it. Some inventories should be filtered, authenticated, or hidden to avoid exposing device capabilities.

CoAP Discovery Quick Reference

Discovery request

Use GET /.well-known/core on the endpoint when the server address is known. Multicast discovery can be used only where scope and security make sense.

Discovery response

A successful response is usually 2.05 Content with application/link-format, registered as CoAP Content-Format number 40.

After discovery

The client chooses a target URI and then uses normal CoAP methods such as GET /sensors/temp or Observe registration on that resource.

rt resource type

Describes what the resource represents, such as temperature-c or light-control. Multiple values can be space separated.

if interface

Describes the interaction pattern, such as a sensor interface, actuator interface, batch collection, or core link batch.

ct, sz, obs

ct lists target representation formats, sz estimates size, and obs is a no-value hint that observation might be useful.

Query form

Filters are query parameters on /.well-known/core, for example ?rt=temperature-c, ?if=core.s, or ?obs.

Filter support

RFC 6690 allows servers to recognize query filters, but a client should not assume every constrained endpoint supports every filter.

Why filter

Filtering reduces payload size, parser work, and radio time. It also helps multicast discovery avoid a burst of oversized responses.

Direct endpoint

The client asks one known server for the links that server exposes. The links are typically relative to that endpoint.

Resource Directory

Endpoints register link-format descriptions with an RD. Clients can later search the RD, such as /rd-lookup/res?rt=temperature-c.

Different trust boundary

An RD can reveal inventory for many endpoints, so registration, lookup, and lifetime handling need policy and access control.

Technical accuracy notes and source links

RFC 6690 scope

The mandatory support statement applies to servers implementing the CoRE Link Format discovery specification, not to every possible CoAP endpoint in the world.

Attributes versus payload

ct on a link describes the target resource formats. The discovery response itself uses application/link-format, shown here as Content-Format 40.

obs is only a hint

A client still has to send an Observe request and check the response. The attribute has no value and does not guarantee successful observation.

RFC 6690 CoRE Link Format RFC 7641 Observe RFC 9176 Resource Directory

Independent practice

Find the best temperature URI

Choose the resource-type filter scenario. Compare the returned link attributes and decide which URI a dashboard should poll or observe.

Separate direct discovery from RD lookup

Switch between full endpoint inventory and Resource Directory lookup. Notice when returned links are local relative paths versus directory-discovered endpoint links.

Audit inventory exposure

Open the protected inventory scenario and list what an attacker could learn if actuator and firmware links were published without authentication.