Résumé

  • Un billet de contributeur publié le 17 septembre sur le blog de LACNIC indique que XARF v4 exige au minimum sept champs. La spécification XARF actuelle en énumère huit au niveau supérieur.
  • Le champ absent du résumé est sender. XARF le sépare de reporter afin qu’un CERT, un prestataire technique ou un autre intermédiaire puisse acheminer un signalement sans devenir le plaignant.
  • Cet écart ne prouve ni la perte d’un message ni l’adoption de XARF par LACNIC. Il justifie un reçu reliant toute validation à une version précise, à la liste des exigences, aux rôles, au transport et au triage.

Un formulaire complet peut encore avoir perdu son expéditeur

Supposons qu’un outil attende sept éléments : version, identifiant, date de l’incident, auteur du signalement, source de l’abus, catégorie et type. Tout est présent ; l’écran devient vert. Pourtant le rapport a été transmis par un CERT national pour le compte d’un membre et aucun champ ne permet de conserver ce fait.

Cette situation hypothétique ne démontre aucun abus ni aucune défaillance réelle. Elle montre comment un résumé documentaire peut devenir une décision de conception.

Le point de départ est le billet « How to Keep an Abuse Report from Getting Lost in Your Mailbox », publié le 17 septembre sur le blog de LACNIC par Guillermo Pereyra. Il présente XARF v4 comme un format JSON maintenu par la communauté, couvrant 32 types d’incidents répartis en sept catégories.

Le billet parle ensuite d’un minimum de sept champs : version du schéma, identifiant unique, horodatage, reporter, source de l’abus, catégorie et type. La spécification technique XARF v4 actuellement publiée en affiche huit : xarf_version, report_id, timestamp, reporter, sender, le champ d’identification de la source, category et type.

La référence des champs communs confirme cette liste et détaille les propriétés obligatoires des deux objets d’organisation. Des champs supplémentaires deviennent obligatoires selon la catégorie. Huit désigne donc le tronc commun de premier niveau, non le nombre total de valeurs d’un rapport complet.

Le billet ne méconnaît pas entièrement ce huitième champ. Le paragraphe suivant explique justement que reporter identifie l’organisation qui a détecté ou dénoncé l’abus, tandis que sender est celle qui transmet le rapport. L’exemple JSON contient les deux. La page précise aussi que les opinions de l’auteur ne reflètent pas nécessairement celles de LACNIC.

La conclusion doit rester étroite. Rien n’établit que LACNIC ait déployé un parseur limité à sept champs, qu’une implémentation XARF ait échoué ou qu’un signalement réel ait été négligé pour cette raison. En revanche, le décalage entre le chiffre et l’exemple est observable.

Le rôle concerné n’est pas accessoire. Dans le cas ordinaire, reporter et sender ont la même valeur. Dans une chaîne déléguée, un prestataire de signalement, une société de protection de marque, un service anti-abus ou un CERT peut transmettre pour une autre organisation. Le destinataire doit alors savoir qui porte l’allégation, qui a opéré le canal et qui peut corriger une erreur technique.

Cette provenance sert aussi à distinguer les doublons. Deux envois du même intermédiaire ne sont pas nécessairement deux plaintes. Deux plaignants passant par un même service ne sont pas nécessairement un seul cas. Réduire les deux rôles à une origine générique rend la file plus simple, mais l’enquête moins reproductible.

La validité du schéma ne constitue d’ailleurs que la première marche. XARF classe source_port, evidence, evidence_source et confidence parmi les champs communs recommandés. Les schémas de catégorie peuvent ajouter leurs propres obligations. Le mode standard exige les champs obligatoires ; le mode strict exige également les recommandations.

Un rapport accepté en mode permissif peut donc ne pas porter de tableau de preuves. Un autre peut joindre un élément sans rapport avec l’incident. Un message parfait peut être refusé par le serveur de courrier, mal routé, laissé sans analyste ou contesté. Syntaxe, livraison, aiguillage, examen, décision et correction sont six états, pas un seul verdict.

Le billet du blog le dit à sa manière : la preuve est recommandée dans le schéma, mais c’est souvent elle qui rend le rapport exploitable. Il maintient aussi le texte libre comme canal valable lorsqu’il indique la ressource touchée, l’heure UTC, le type d’abus, une preuve et un contact joignable. Un bon message reste supérieur à un mauvais JSON.

La section 12 du Manuel des politiques de LACNIC fixe le contexte régional. Elle exige un contact d’abus activement géré, accepte des signalements manuels ou automatiques et interdit d’imposer un formulaire. Elle ne prescrit pas XARF et ne confère pas au validateur la faculté de juger les faits.

Même limite pour le transport. Le billet cite ARF et RFC 5965. Ce RFC définit un format extensible de retour par courrier électronique, mais laisse hors de son périmètre la destination, la validation du contenu et la confiance entre émetteur et destinataire. RFC 6650 précise ensuite les usages. Une enveloppe structurée ne décide pas du fond.

La bonne unité de contrôle est un reçu d’admission. Il conserve le nom et la version sémantique du schéma, l’empreinte de la documentation ou du fichier appliqué et la liste exacte des champs communs et propres à la catégorie. Il préserve séparément reporter et sender, même si leurs valeurs coïncident.

Il ajoute le mode de validation, le résultat et les avertissements ; le nombre de pièces et l’empreinte du lot lorsqu’il existe ; l’identifiant de transport, le point de réception et l’heure ; la file responsable, l’état du triage et la voie de correction. Une empreinte prouve l’identité des octets, pas la vérité de l’allégation.

Une correction de documentation devient alors réversible. Le destinataire retrouve les rapports évalués selon l’ancienne règle et ne réexamine que cet ensemble. Sans reçu, « XARF valide » flotte entre une page, une version de code et une interprétation locale.

Sources