Find a copy through HTTP
03The ni name identifies data. A retrieval mapping supplies an HTTP or HTTPS location where a copy might be found.
Separate example: /files/sha-256;<digest> is just a URL segment. Its appearance alone does not promise this specification or a successful integrity check.
Source for this drawing: RFC 6920 · Read RFC section 4 ↗
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.
The .well-known algorithm path is sha-256, including the hyphen. The printed sha256 path is a verified editorial error, not a different registered suite.
Read the updated RFC section ↗The mapping changes /alg;val into /.well-known/ni/alg/val and preserves the query. A nonempty authority MUST stay the same.
- The mapping changes /alg;val into /.well-known/ni/alg/val and preserves the query. A nonempty authority MUST stay the same.
- If the ni authority is absent, an HTTP authority MAY come from application context. Availability is not guaranteed; clients using this mapping MUST handle HTTP redirection.
- Choosing HTTP or HTTPS belongs to the application and its policies; a digest does not supply confidentiality. A similar-looking segment in an arbitrary URL MUST NOT imply RFC6920 compliance (§5).
Also RFC6920 §§3,5,8.1–8.2. Verified editorial erratum4248 repairs sha256 to sha-256 in§8.2. Worked values are public RFC examples or fictional teaching data. Naming, locating, and checking integrity are distinct operations.
Read the RFC section ↗