Re: Message sans texte

Bonjour LaPinaille :-)

Je cite e-s parce que sa politique vient contredire ce que tu affirmais
précédemment mais je ne cite pas sans arrêt e-s et il n'y a pas, ici, de
RFC pour donner crédit à mes propos.

J'affirme que la RFC 8315 qui formalise les Cancel-Locks dans les articles netnews ne mentionne pas d'autres vérifications à effectuer que celle du contrôle CL/CK pour s'assurer de l'authenticité du cancel avant de décider de l'honorer. Point barre.
Lis là comme tu veux, c'est comme ça.
https://www.rfc-editor.org/rfc/rfc8315#section-3.5
Les vérifications que tu évoques à l'envie ne sont NULLEMENT un pré-requis pour honorer/refuser un cancel/superseede.
Le seul fait que le contrôle CL/CK soit correct est considéré comme une authentification et ne nécessite pas de vérification supplémentaire pour identifier son auteur. RFC 8315 => "The Cancel-Key header field contains one or more of the secret strings that were used to create the Cancel-Lock header field of the original article.  Knowledge of *at* *least* *one* of the secret strings is required to create a match for *successful* *authentication*".
https://www.rfc-editor.org/rfc/rfc8315#section-3.3
De plus, vérifier autre chose que la paire CL/CK n'est pas vraiment conforme à l'esprit du texte, qui indique dès son introduction : "One property of this system (CL/CK) is that it prevents *tracking* of *individual* users".
https://www.rfc-editor.org/rfc/rfc8315#section-1
Pour autant, si la RFC ne le recommande pas, rien n'interdit d'effectuer ces (ou même d'autres) vérifications si l'administrateur en éprouve le besoin (ou l'envie). Dans ce cas précis, cela ne relève pas des précaunisations des RFC mais de la politique de traitement des annulations du serveur, mise en place par son administrateur (Et je suis prêt à parier que cela ne sera plus forcément pareil lorsque INN 2.8 sera déployé puisqu'il ne délèguera plus le controle des CL/CK a une appli tierce).
Tu ne prouves donc rien en affirmant que tel ou tel serveur fait plus (ou moins) que ce qui est prévu par la RFC 8315, qui reste, que ca te plaise ou non, *LA* référence pour les CL/CK.
Et puisque tu aimes la précision, ces vérifications supplémentaires que tu évoques sont également disponibles lors d'un POST sur un serveur SNS (uniquement si l'administrateur l'a configuré pour passer outre le comportement "par défaut", qui est celui de la RFC 8315). Cela n'a pas un grand intérêt, complexifie d'autant les annulations, mais c'est tout de même possible.
Il en va de même pour les articles d'annulation reçus par un feed pour lesquels  l'administrateur dispose de 4 choix de traitements possibles ("Tous", "aucun", "avec CL/CK valide ou sans CL/CK" et "uniquement si CL/CK valide"). C'est exactement la même chose dans INN (All / None / Auth et ReqAuth) et c'est pour ca que chaque serveur se comporte différement avec les annulations. S'il est configuré pour ne pas les honorer, tu peux envoyer tous les CK valides que tu veux, ils ne seront jamais honorés.
Voilà j'epère avoir été suffisament précis mais tu peux toujours "pinailler" si tu n'y resistes pas, je m'en branle un peu en fait :-)
Bah oui, je n'ai jamais rencontré ton problème d'annulation et d'être obligé de filer mon CK à quelqu'un pour y parvenir.

De même pour pasdenom.info ou pour csiph qui, lui, n'honore pas les
cancels et sans doute pas les supersedes ou encore pour news.free.fr qui
ignore CK et CL.

Pow, pow, pow!
Pour traiter les CL/CK, il faut bien évidement que le serveur les prenne en charge et qu'il soit configuré pour les honnorer (voir supra).
Ta référence à Free est une abération, puisqu'ils utilisent une version datant d'une époque où les CL/CK n'existaient même pas! Comment veux-tu qu'ils les traitent? C'est tellement vieux que même CAPABILITIES n'est pas supporté! C'est dire.
A vouloir faire le show avec tes roulades, tu en devient ridicule.
Dois-je aussi préciser qu'un client qui n'implémente pas les CL/CK n'est pas en mesure de les placer seul dans ses articles mais qu'il peut déléguer cette tâche à un serveur? Ou ça c'est bon?
Oui?

Tu essayes seulement de me discréditer :

Tu peux toujours jouer la victime éplorée mais personne n'est dupe.
Tu passes ton temps à attaquer les uns et les autres, à conterdire sans aucun argument, à placer tes "c'est partiellement vrai", à critiquer le moindre "bug" que tu penses avoir découvert (mon dieu qu'il était risible ton "merci moi" que tu nous a sorti pour les entêtes de Macafé).
Tu passes ton temps à vomir tes demandes de corrections comme si l'auteur de Macafé te devait quoique ce soit.
Mais toi Vauquois, tu as fait quoi exactement avec tes dix doigts et ton neurone?
Montre nous tes pépites informatiques, fais donc profiter la communauté! Gratuitement bien entendu.
Donc non Vauquois, je n'ai absolument pas besoin de vouloir te discréditer. Crois-moi sur parole, tu t'en sors très bien sans mon aide.
Tu es l'archétype même du troll de base, la crétinerie en plus.

c'est stérile.

Phrase traditionnelle lorsque l'on manque cruellement d'argumentation et qu'on est arrivé au bout de sa démonstration.

Et si tu penses que je passe mon temps à pinailler et que je suis
fatigant, libre à toi de ne pas me lire et, mieux encore, de ne pas me
répondre. ;-)

Meuh non! Surtout pas malheureux!!!
N'étant pas assez précis dans mes explications, c'est bien d'avoir un sbire pour la relecture et pour y apporter du contenu... Pertinent et succulent :-)
Sérieusement Vauquois, tu as fais ma journée avec ton "pas besoin que ce soit la même personne" tout en précisant avoir "volontairement donné ton CK" à "une tierce personne" ;-).
La crétinerie en plus je te dis!
Alors?
Plonkera, plonkera pas?
Redirigera, redirigera pas?
Pow, je supporte plus ce suspens!
:-)