This subclause provides a walkthrough of the process a client would use to find a resource of interest using the appropriate portions of this standard.
Link-layer joining is not covered in this standard. Refer to the appropriate specification for details regarding joining the appropriate data link-layer network.
The following sequence demonstrates the discovery process using DeviceCapabilities (as opposed to Function Set Assignments). This sequence assumes some knowledge either from other specifications or from other subclauses in this document, therefore these may need to be read before this sequence is fully understood.
a) Use xmDNS/DNS-SD to locate the servers with the function sets of interest (See IETF Extended Multicast DNS Internet Draft, and IETF RFC 6763).
b) For each server do the following:
1) Establish TLS session if required (see Clause 6).
2) GET the Device Capabilities resource (See 8.3).
3) Look for the desired function set in the Device Capabilities resource.
4) If there is an entry in Device Capabilities it will contain a URI of the entry point for that function set.
5) Alternately, use the path returned in the subtype query response (See 7.5).
c) Determine which of the discovered resources are of interest. This depends on the resource and other outside factors (e.g., if the resource is “metering,” then the meter of interest might be the one that has the Premises Aggregation Point attribute set to true).
It should be noted that clients SHALL dynamically discover the URI(s) of the resource(s) of interest, as the URI(s) MAY vary from server to server and MAY occasionally vary over the lifetime of a given server. Clients SHALL rediscover URIs upon notification of the server DNS-SD record change or a request fails with a 404 (Not Found) error. Clients SHALL, in the case of redirects, follow the guidance in the HTTP specification (IETF RFC 7231).