Serialize without a path
05Serialization turns an origin into text. Default ports disappear; non-default ports remain. ASCII and Unicode forms differ for international host labels.
The same triple has Unicode serialization https://bücher.example. It is a display form defined by §6.1, not the ASCII field value.
Source for this drawing: RFC 6454 · Read RFC section 6 ↗
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 Origin field uses ASCII serialization, not a display-friendly Unicode name.
- A triple becomes scheme://host, followed by :port only when its port differs from the protocol default. No path, query, fragment or trailing slash is appended.
- The Unicode form replaces A-label host components with their corresponding U-labels. The ASCII form keeps the host in ASCII; Origin field values MUST use this ASCII form.
- A non-triple origin serializes as null in either form. Serialization is a representation, not proof of identity, trust or permission.
Chosen IDNA example: xn--bcher-kva.example corresponds to bücher.example. This is a fixed mapping illustration, not an IDNA validator or a recommendation to compare rendered names. The guide covers RFC 6454, including its host-processing assumptions.
Read the RFC section ↗