Compare content names, not hosts
02Two names identify the same thing only when their decoded digest algorithm, length and binary value match.
Separate case: a sha-256-32 name contains the first four bytes only. It MUST NOT be considered equal to the full sha-256 name.
Source for this drawing: RFC 6920 · Read RFC section 2 ↗
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.
Implementations MUST compare the digest algorithm and digest value and MUST NOT use authority or parameters when comparing these names.
- Implementations MUST compare the digest algorithm and digest value and MUST NOT use authority or parameters when comparing these names.
- Equivalent supported encodings MUST compare by decoded bytes, algorithm and length. A prefix alone is not equality (§10).
- Authority is an optional location hint, with no default value (§3); it does not establish ownership of matching content (§10).
Also RFC6920 §§3,10. The helper recognizes the six initial suites; algorithm-name case ambiguity is held erratum8174, not a new lowercase-only syntax rule. Worked values are public RFC examples or fictional teaching data. Naming, locating, and checking integrity are distinct operations.
Read the RFC section ↗