I don't know how to put it in text yet (otherwise this'd be a PR), but I'd like to capture a concept here:

One is tempted to place consumers of data that contains identifiers into two categories: those that dereference, and those that have hard-coded knowledge of the identifiers' meanings. I think this is oversimplifying, as there is really a continuum:

1. The consumer dereferences on every use.
2. The consumer dereferences but caches.
3. The consumer dereferences through a caching proxy (that does not include any Forwarded-For or similar headers).
4. The consumer dereferences through a caching proxy that has the same authentication requirements as the consumer's firmware update server.
5. The caching proxy only allows access to URIs advertised in some public directory (possibly eagerly caching them).
6. The caching proxy only allows access to whitelisted URIs.
7. The caching proxy filters the content of dereferenced representations down to what the consumer is known to process.
8. The caching proxy serves representations managed by the firmware authors.
9. The caching proxy converts the representations into a format custom to the consumer (for example a .so / .dll library)
10. When the consumer firmware is built, it is pre-provisioned with cache entries from the proxy.
11. The semantics of all relevant identifiers are hardcoded into the firmware.

Somewhere around 5 the client is as good as hardcoded against the privacy thread model of the document author tracking users (while retaining the ability of authors to create identifiers on demand), and at 10 even against the firmware author's tracking (although the firmware author likely has other means anyway).

A large part of this are cache lifetimes. Hardcoding identifiers' semantics as in 11 is equivalent to the developer asserting that the document has infinite validity over time; anything starting from 3/4 may also start making such (possibly unfounded) assertions. Conversely, identifier authors can support good use of their descriptive resources by giving them long lifetimes (a bit easier on HTTP than on CoAP b/c HTTP clients can re-validate). Long lifetimes would also solve the longevity issue, except that an HTTP advertised Max-Age of a century would really need to be bounded to how long the owner of the DNS name is guaranteed control over that name (can one even pay for names many years ahead? Even if so, how long are the operators' contracts with ICANN?). Well, at least the intention can be documented in there.