Compatibility and trust limits
05The successor removes mandatory Latin-1 support but keeps UTF-8 required. Successful decoding still cannot prove that similar-looking or multilingual values mean the same thing.
The English label Paid and the French label À payer (to pay) do not mean the same thing. Both can decode successfully. Parameter-specific handling is needed; syntax alone is not a translation or trust check.
Source for this drawing: RFC 8187 · Read RFC section 5 ↗
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
- Historic
- The current status of superseded RFC 5987; RFC 8187 remains Proposed Standard.
- Confusable
- Different characters whose displayed shapes can look alike.
- Language variant
- Text supplied in a particular language; valid encoding does not prove semantic equivalence.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The successor removes mandatory ISO-8859-1 recipient support. UTF-8 remains required; legacy Latin-1 support is encouraged for compatibility, while current producers MUST use UTF-8.
Read the updated RFC section ↗Encoding text makes it readable; it does not establish identity or equivalent meaning.
- RFC 8187 obsoletes RFC 5987, now Historic. Producers MUST use UTF-8 and recipients MUST support it. Mandatory recipient support for ISO-8859-1 was removed; recipients are still encouraged to support that legacy encoding for compatibility.
- Non-ASCII text permits visual spoofing. Distinct code points may look alike, so a successfully decoded label is not proof of identity or equivalence. Invalid UTF-8 must not be treated as valid characters; see RFC 3629 §§3–4 and §10.
- Multiple language variants can convey non-equivalent meanings. Whether that is exploitable depends on the parameter and its field-specific processing; RFC 8187 defines neither a translation checker nor a universal security decision.
Appendix B is an implementation report from 2017, not a current browser-adoption survey. The examples here are fictional labels, not real accounts, credentials or an attack on a site. The two language variants are independent candidate values, not permission to repeat an extended parameter name in one field.
Read the RFC section ↗