Visual RFC.
ALL RFCs / RFC 8187
Read the RFC ↗
RFC 8187 / RECOVERY AND TRUST

Handle errors and fallback deliberately

04

Recipients need robust handling of malformed escapes and invalid UTF-8, but this RFC does not prescribe one recovery algorithm. Parameter precedence belongs to the adopting field’s rules.

DIAGRAMRead RFC section 4.2 ↗
RFC 8187 · § 4.2EXAMPLE
3 / 3
Handle errors and fallback deliberatelyTwo independent malformed examples fail percent-escape or UTF-8 validation, so neither is delivered as a successfully decoded value. The next state presents ignoring the parameter, stripping a bad sequence and substituting a replacement as alternative recovery choices, not a prescribed order. The official fallback/extended title example then selects the extended euro title under an explicitly assumed adopting-field policy following the RFC suggestion. No universal duplicate or fallback MUST is invented.Detect the error; use a defined policytitle="EURO exchange rates"title*=utf-8''%e2%82%ac%20exchange%20ratesexample field policyChosen: € exchange ratesSuggested precedence · follow the field’s rules
03
Select the extended title under the example field’s policy.

The official example offers title="EURO exchange rates" and title*=utf-8''%e2%82%ac%20exchange%20rates. A recipient following the suggested precedence chooses € exchange rates; the fallback remains for legacy recipients.

Source for this drawing: RFC 8187 · Read RFC section 4.2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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

RFC 3629 UTF-8 RFC 9110 HTTP

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Malformed escape
A percent sign without exactly two following hexadecimal digits in the encoded sequence.
Replacement character
A visible substitute such as U+FFFD for a sequence that cannot be decoded.
Fallback
An ordinary ASCII parameter accompanying the extended value for older recipients.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Detect invalid encoding without inventing a universal recovery or fallback rule.

  • Malformed or incomplete percent escapes and non-decodable byte sequences need robust handling. RFC 8187 lists ignoring the parameter, stripping a bad sequence or substituting a replacement character as acceptable strategies; it mandates none of these particular strategies.
  • Field specifications need to define whether repeated identical parameter names are allowed and how they are processed. RFC 8187 advises against multiple extended parameters with identical names for MIME compatibility; it does not supply one duplicate-resolution algorithm.
  • RFC 8187 suggests that extended syntax take precedence over a corresponding ordinary parameter. Its example carries an ASCII fallback and a UTF-8 title*. This suggestion is not a universal uppercase MUST overriding field-specific rules.
DETAILS

The malformed %G0 and overlong UTF-8 C0 AF examples illustrate failed decoding, not an RFC-required rejection of the entire response. The fallback example assumes an adopting field follows the suggested precedence. title and title* are different names; that example does not authorize repeated identical title* names.

Read the RFC section ↗

All chapters in RFC 8187

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗