URI Fragment Identifiers for the text/plain Media Type
This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust. [STANDARDS-TRACK]
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 12 must, 4 should, 4 may.
2 Fragment Identification Methods
- MUSTWhen interpreting character or line numbers, implementations MUST take the character encoding of the MIME entity into account, because character count and octet count may differ for the character encoding being used.
2.1.1 Positions and Ranges
- SHOULDSince positions are fragments of length zero, applications SHOULD use other methods than highlighting to indicate positions, the most obvious way being the positioning of a cursor (if the application supports the concept of a cursor).
- SHOULDApplications that support a concept such as highlighting SHOULD use such a concept to indicate fragments of lengths greater than zero to the user.
2.1.2 Characters and Lines
- MUSTFragments identified by lines include the line endings, so applications identifying line-based fragments MUST include the line endings in the fragment identification they are using (e.g., the highlighted selection).
2.3 Fragment Identifier Robustness
- MUSTIntegrity-check information may specify the character encoding that has been used when creating the information, and if such a specification is present, clients MUST check whether the character
- MUST NOTencoding specified and the character encoding of the retrieved MIME entity are equal, and clients MUST NOT use the integrity check information if these values differ.
- MAYHowever, clients MAY choose to transcode the retrieved MIME entity in the case of differing character encodings, and after doing so, apply integrity checks.
3 Fragment Identification Syntax
- MUSTNOTE: In the descriptions that follow, specified text values MUST be used exactly as given, using exactly the indicated lower-case letters.
3.1 Integrity Checks
- MUSTTo allow future changes to this specification to address developments in cryptography, implementations MUST ignore new types of integrity checks, with names other than 'length' and 'md5'.
4 Fragment Identifier Processing
- MUSTApplications implementing support for the mechanism described in this memo MUST behave as described in the following sections.
4.1 Handling of Line Endings in text/plain MIME Entities
- MUSTIndependent of the number of bytes or characters used to represent a line ending, each line ending MUST be counted as one single
- MUSTImplementations interpreting text/plain fragment identifiers MUST take into account the line ending conventions of the protocols and other contexts that they work in.
- SHOULDAll implementations SHOULD support the Internet-wide CR+LF line ending convention, and MAY support additional conventions not related to the protocols or systems they work with.
4.2 Handling of Position Values
- MUSTIf a range scheme's positions are not properly ordered (i.e., the first number is less than the second), then the fragment identifier MUST be ignored.
4.3 Handling of Integrity Checks
- MAYClients are not required to implement the handling of integrity checks, so they MAY choose to ignore integrity check information altogether.
- SHOULD NOTIf a fragment identifier contains one or more integrity checks, and a client retrieves a MIME entity and, using some integrity check(s), detects that the entity has changed (observing the character encoding specification as described in Section 3.1, if present), then the client SHOULD NOT interpret the text/plain fragment identifier.
- MAYA client MAY signal this situation to the user.
4.4 Syntax Errors in Fragment Identifiers
- MUSTIf a fragment identifier contains a syntax error (i.e., does not conform to the syntax specified in Section 3), then it MUST be ignored by clients.
- MUST NOTClients MUST NOT make any attempt to correct or guess fragment identifiers.
- MAYSyntax errors MAY be reported by clients.