Résumé

  • RFC 5147 ajoute à text/plain des fragments fondés sur des positions ou plages de caractères et de lignes.
  • Le fragment est traité par le client après récupération ; le serveur d’origine ne l’emploie pas pour résoudre la ressource.
  • Une position compte depuis zéro et désigne une frontière de longueur nulle, non une citation.
  • Les caractères sont comptés après décodage ; un octet, un point de code et un signe perçu ne sont pas équivalents.
  • Les fins de ligne reconnues comptent chacune pour un caractère, quelle que soit leur représentation locale.
  • Une position au-delà du contenu est ramenée à la fin de l’entité, sans démontrer que le passage existe encore.
  • Une plage inversée ou une syntaxe fautive doit être ignorée, jamais corrigée par conjecture.
  • Les paramètres facultatifs length et md5 portent sur l’entité MIME décodée des encodages de transport.
  • Un client peut ignorer ces contrôles ; un changement de charset peut interdire le contrôle ou rendre le transcodage incertain.
  • MD5 peut signaler une dérive accidentelle dans ce protocole ancien, mais n’authentifie ni auteur ni version normative.
  • L’affichage du seul fragment peut masquer le contexte, les réserves juridiques ou l’origine réelle du contenu.
  • Une décision exige des reçus distincts pour la révision, les octets, le décodage, le contexte, l’émetteur et l’autorisation.

Le fichier retrouvé n’était pas la même entité

L’équipe d’archivage avait rempli son objectif apparent. Le chemin répondait. Le contenu était lisible. Les phrases semblaient intactes. Pourtant, le fichier avait été converti d’un encodage historique vers UTF-8, et certaines séquences composées n’occupaient plus le même nombre de points de code.

Une position de caractère RFC 5147 ne compte pas les octets. Elle commence après le décodage de l’entité text/plain. Un BOM initial ne compte pas comme caractère. Les séquences de plusieurs octets et les caractères composés imposent donc une connaissance exacte du charset. Le lien avait survécu comme chaîne ; sa géométrie avait changé.

Cette distinction est utile pour une direction qui confie ses preuves à des archives, des passerelles ou des systèmes de gestion documentaire. La conservation sémantique ne se déduit pas d’une conversion réussie. Il faut savoir quelle représentation a servi à fabriquer le fragment et quelle représentation le client a effectivement comptée.

La sélection appartient au client

Le composant situé après # n’est pas une requête adressée au serveur pour qu’il certifie un passage. RFC 5147 reprend le modèle générique des URI : la ressource est résolue et récupérée, puis le client applique la sémantique de fragment associée au type de média.

Cette architecture permet un déploiement progressif. Un logiciel ignorant RFC 5147 peut ouvrir le document complet. Mais ce succès est ambigu. Il confirme la disponibilité de l’entité, pas le repérage du sous-ensemble. Deux lecteurs recevant les mêmes octets peuvent présenter des résultats différents si l’un comprend line= et l’autre non.

Dans une chaîne d’audit, il faut donc distinguer au moins : résolution, récupération, type MIME, décodage, interprétation du fragment et rendu. Un statut unique « lien valide » efface précisément l’étape qui porte la preuve attendue.

Quatre formes, aucune identité sémantique

Le modèle combine caractères ou lignes avec position ou plage. La position zéro précède le premier élément. Une position est un point sans longueur ; une plage couvre l’intervalle entre deux positions. Une application qui transforme un curseur en extrait doit conserver cette différence.

Les plages de lignes comprennent leurs fins de ligne. Or Internet, HTTP et les systèmes de fichiers ne représentent pas toujours ces fins de la même manière. CRLF, LF, CR et d’autres conventions peuvent apparaître. RFC 5147 exige que chaque fin de ligne reconnue compte comme un caractère, mais le client doit connaître la convention pertinente.

L’uniformité apparente d’un écran ne garantit donc pas l’identité de l’entité. Un dépôt peut normaliser CRLF en LF sans modifier les mots. Un outil de preuve qui hache les octets avant conversion mais compte les caractères après conversion observe deux réalités et ne peut pas les fusionner dans un seul identifiant.

La fin du document peut ressembler à une réussite

Une valeur supérieure à la longueur réelle désigne la dernière position du document. Cette règle évite une erreur indéfinie, mais elle ne confirme pas que la cible historique existe.

Si une politique de 600 lignes est remplacée par un avis de 40 lignes, un ancien fragment visant la ligne 520 peut conduire au bas du nouvel avis. Le moteur a appliqué la spécification. La preuve métier a disparu. Il faut enregistrer le fait que la position a été bornée, et le traiter comme une rupture de référence.

Les plages ouvertes ont un autre risque. line=,10 commence au début ; line=10, continue jusqu’à la fin. Après une extension, la sélection peut englober des pages supplémentaires. La chaîne d’URI ne dit pas combien de texte le créateur avait vu.

À l’inverse, une plage mal ordonnée doit être ignorée. Une syntaxe incorrecte doit aussi l’être, sans tentative de réparation. Cette interdiction de deviner protège la reproductibilité. Mais l’interface doit annoncer clairement l’échec ; sinon, le document complet affiché donne l’illusion que le fragment a réussi.

Les contrôles d’intégrité ont une portée étroite

RFC 5147 autorise l’ajout de length ou md5. La longueur est qualifiée de contrôle très faible. MD5 compare la représentation binaire de l’entité, après retrait des encodages de contenu ou de transfert qui appartiennent au transport.

Le contrôle peut préciser le charset. Si celui-ci diffère de l’entité récupérée, le client ne doit pas utiliser le résultat. Il peut transcoder avant de comparer, mais la spécification prévient que la perte ou la normalisation de caractères rend cette opération intrinsèquement incertaine.

Surtout, la mise en œuvre des contrôles n’est pas obligatoire. Un client peut les ignorer. S’il les comprend et détecte un changement, il devrait ne pas interpréter le fragment et peut prévenir l’utilisateur. Une organisation ne peut donc pas déduire une politique d’arrêt uniforme du simple fait que le lien contient un digest.

RFC 6151 fixe ensuite la limite cryptographique : MD5 n’est plus acceptable quand la résistance aux collisions est requise, notamment pour les signatures. Dans RFC 5147, un MD5 concordant peut servir de témoin historique de dérive accidentelle. Il ne prouve pas que l’entité vient de l’autorité compétente, qu’elle est la version applicable ou que le décideur peut agir.

Le type de média commande la grammaire

Le fragment n’a pas le même sens pour tous les formats. RFC 5147 ne vaut que pour text/plain. Certains environnements, notamment des fichiers locaux ou des transferts sans métadonnée fiable, obligent le client à inférer le type. La spécification qualifie cette situation d’intrinsèquement peu fiable.

Une extension .txt n’est pas une attestation MIME. Un stockage local peut appliquer ses propres fins de ligne. Une passerelle peut fournir un charset par défaut. Le même URI logique passe alors par des contrats de traitement différents.

L’inscription IANA relie officiellement text/plain à RFC 5147. Elle atteste une coordination documentaire. Elle ne mesure ni l’adoption par les navigateurs, ni l’exactitude d’un rendu, ni le taux de contrôle des paramètres d’intégrité. Une entrée de registre ne doit pas être transformée en métrique d’exploitation.

Montrer moins peut changer le sens

La section sécurité ne se limite pas aux erreurs de comptage. Elle avertit que des logiciels peuvent afficher différemment un document ou son fragment. Une inclusion qui ne montre que la plage peut cacher des conditions en petits caractères ou présenter un signe de confiance hors de son contexte.

Le texte peut être authentique et la présentation trompeuse. La sélection peut être correcte et l’inférence fausse. La défense consiste à rendre visibles les limites de l’inclusion, à contrôler les domaines de sécurité et à préserver l’accès au contexte complet.

Pour une preuve durable, le reçu doit contenir l’URI complet, l’instant de récupération, les validateurs de réponse, le type déclaré et effectif, le charset, le hash de l’entité décodée, la politique de fins de ligne, la chaîne de fragment, le logiciel de lecture, le texte sélectionné et son voisinage. La signature et l’autorité éditoriale viennent ensuite, dans des reçus séparés.

Sources

  1. RFC 5147, HTML
  2. RFC 5147, texte
  3. Fiche RFC Editor
  4. Fiche IETF Datatracker
  5. Historique du document
  6. Recherche d’errata RFC 5147
  7. RFC 6838 : spécifications des types de média
  8. RFC 2046 : types de média MIME
  9. RFC 3986 : syntaxe générique des URI
  10. RFC 3987 : identifiants internationalisés
  11. RFC 3629 : UTF-8
  12. RFC 1321 : MD5
  13. RFC 6151 : sécurité de MD5
  14. RFC 9110 : sémantique HTTP
  15. RFC 8089 : schéma URI file
  16. Registre IANA des types de média
  17. W3C Media Fragments URI 1.0
  18. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  19. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  20. Running-Code Primacy