Separate resolution parameters from queries
04An r-component is intended for a resolution service. RFC 8141 reserves its syntax, while leaving exact service semantics to other standardization.
Separate case with no standardized r semantics: apply SHOULD NOT use before standardization. This chosen conservative behavior stops the r-based request rather than inventing a working service.
Source for this drawing: RFC 8141 · Read RFC section 2.3.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Recognizing ?+ does not create a supported resolver service.
- The r-component SHALL be supplied with the URN when presenting a request to a resolution service, and SHALL NOT affect URN-equivalence.
- RFC 8141 says r-components SHOULD NOT be used before their semantics have been standardized. Its country-selection example is hypothetical, not an assigned universal service.
- Resolution systems MUST NOT require q-component information for processing. Clients SHOULD NOT pass f-components to a resolution service unless that service also retrieves and interprets objects.
These are separate schematic cases. The first exchange assumes appropriate separately standardized semantics and a chosen resolver. No actual resolution protocol, discovery, endpoint, country code service or current registry is implemented. The final gate applies when that assumption is absent.
Read the RFC section ↗