Character encoding is not fixed for text/plain, so character counting requires knowing the encoding. Multi-byte encodings (e.g., UTF-16) make octet offsets unreliable; BOM marks do not count as characters. This variability necessitates encoding-aware position calculation.

Fragment identifiers are interpreted solely by the client after retrieval; a server cannot determine whether a requesting client supports or will interpret a fragment identifier. This client-side-only scope simplifies the protocol but means robustness must be handled on the client.

Integrity checks are defined on MIME entities rather than on the resource itself because fragment identifiers are evaluated client-side after retrieval. Content-encodings and transfer-encodings must be stripped before computing or verifying integrity check values.

The 'length' scheme is intentionally a weak integrity check, included because it is easy to compute. The 'md5' scheme provides a stronger check using the MD5 algorithm (RFC 1321), encoded as 32 hexadecimal digits representing the 128-bit result.

crypto

Line endings vary across platforms and protocols: CR+LF (Internet/Windows), LF (Unix), CR (classic MacOS), NEL, and CR+NEL are all possible. Implementations must handle the conventions of their deployment context, and all SHOULD support CR+LF.

Older or non-conforming clients that do not support text/plain fragment identifiers will still retrieve the full resource but will fail to locate the sub-resource; this is an acceptable fallback since fragment evaluation is local to the client.

URI schemes such as FTP that do not provide explicit media type information make text/plain fragment identifier processing inherently unreliable; clients must infer the media type heuristically, and should apply this processing only when the inferred type is text/plain.

All implementations SHOULD support the Internet-wide CR+LF line ending convention and MAY support additional conventions such as bare LF (Unix), bare CR (classic MacOS), NEL, or CR+NEL.

Applications SHOULD use cursor positioning (rather than highlighting) to indicate zero-length position fragments, and SHOULD use highlighting to indicate fragments of length greater than zero.

Each line ending MUST be counted as one single character, independent of the number of bytes or characters used to represent it. Implementations MUST take into account the line ending conventions of the protocols and contexts they work in.

Fragment identifiers containing a syntax error (not conforming to the Section 3 ABNF) MUST be ignored. Clients MUST NOT attempt to correct or guess fragment identifiers; syntax errors MAY be reported.

Fragment identifiers identified by lines MUST include the line endings in the fragment they identify (e.g., in the highlighted selection); line-based fragment inclusion is inclusive of trailing line endings.

If any position value exceeds the actual length of the MIME entity, it is treated as referring to the last position. If a range's first position value is greater than the second (improperly ordered), the fragment identifier MUST be ignored.

If integrity checking is implemented and a mismatch is detected (entity has changed), the client SHOULD NOT interpret the fragment identifier, and MAY signal this situation to the user.

Implementations MUST ignore new types of integrity checks (names other than 'length' and 'md5'), to allow future cryptographic agility. If multiple integrity checks are present, an implementation may use whichever it understands.

crypto

Implementations MUST take the character encoding of the MIME entity into account when interpreting character or line numbers, because character count and octet count may differ (e.g., UTF-16 uses two or four octets per character and may include a BOM).

When an integrity check specifies a character encoding, clients MUST verify that it matches the retrieved MIME entity's encoding, and MUST NOT apply the integrity check if they differ (though they MAY transcode first and then apply the check).

A position is a zero-length fragment pointing between characters or lines, not a character or line itself. Positions are zero-indexed: position zero is before the first character/line; a MIME entity with n characters has n+1 distinct character positions.

A range specifies both a lower and upper bound. Either bound may be omitted, defaulting to the start or end of the MIME entity. A range with equal start and end is legal and identifies a zero-length fragment equivalent to a position.

Integrity checks can be appended to a fragment identifier using the 'length' or 'md5' schemes, optionally followed by a MIME charset. The 'length' scheme specifies character count; the 'md5' scheme specifies a 32-hexdigit MD5 fingerprint of the MIME entity after stripping content-encodings.

crypto

The 'char' scheme identifies a character position (single number) or character range (two comma-separated numbers) within a text/plain MIME entity. Character positions are zero-based, counting each character separately, with line endings always counted as one character regardless of byte representation.

The 'line' scheme identifies a line position (single number) or line range (two comma-separated numbers) within a text/plain MIME entity. Line position zero is always identical to character position zero; identified line fragments include the line endings.

IANA updated the text/plain Media Type registration (originally in RFC 2046) to include a reference to RFC 5147, recording the fragment identifier specification for this media type.

registry

Countermeasures against fragment-based content spoofing include displaying included content within clearly visible boundaries and limiting inclusion to material from the same security realm or from realms giving explicit permission. Implementers should also consult the security considerations in RFC 3986 and RFC 3987.

security

Differential behavior between clients that support and those that do not support text/plain fragment identifiers can enable spoofing or phishing. An attacker could use a fragment identifier to display only a misleading portion of a document (e.g., hiding small-print legal text, or showing site-key-like material to fake legitimacy).

security

Fragment identifiers follow the ABNF: text-fragment = text-scheme 0*(';' integrity-check), where text-scheme is 'char=' or 'line=' followed by a position or range, and integrity-check is 'length=' number or 'md5=' 32HEXDIG, each optionally followed by ',' mime-charset. All scheme names are lowercase.