Re: Supersedes sans cancel-key/cancel-lock

Liste des Groupes 
Sujet : Re: Supersedes sans cancel-key/cancel-lock
De : om+news (at) *nospam* miakinen.net (Olivier Miakinen)
Groupes : fr.usenet.distribution
Date : 30. Oct 2024, 18:50:26
Autres entêtes
Organisation : There's no cabale
Message-ID : <vftrl2$epc$1@cabale.usenet-fr.net>
References : 1 2 3 4 5 6 7
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4
Le 30/10/2024 18:23, M.V. m'a répondu :
 
Je comprends qu'eternal-september n'accepte pas d'annuler un article
protégé par Cancel-Lock, si le Cancel ou le Supersedes n'a pas le bon
Cancel-Key.
 
E-S n'est pas le seul.

Et c'est très bien. Si quelqu'un trouve utile, nécessaire, ou même
indispensable, de protéger certains de ses articles ou tous ses articles
avec un Cancel-Lock, il est normal qu'il s'attende à ce que lui seul
puisse les annuler avec le bon Cancel-Key. Et ce sera le cas sur les
serveurs tels qu'eternal-september qui implémentent cette fonction.

Mais pour un article sans aucun Cancel-Lock, il devrait s'assurer de la
compatibilité avec ce qui se faisait avant le RFC 8315 de 2018. Et donc
accepter d'annuler un article non protégé, au moins si l'auteur de
l'annulation ou du remplacement est le même que l'auteur de l'article
d'origine non protégé.
 
Si les serveurs tels que E-S ne se satisfont plus de la simple
vérification de l'identité de l'auteur de l'annulation ou du
remplacement, c'est sans doute pour de bonnes raisons : ce n'est plus
suffisant.

Pour qui n'est-ce plus suffisant ? Pour moi qui ai toujours considéré usenet
comme un lieu d'entraide sur divers sujets, où les réponses sont censées
être données dans les jours qui suivent (d'où une rétention inutile au delà
d'un mois), le mécanisme de Cancel-Lock/Cancel-Key m'a toujours semblé peu
utile.

--
Olivier Miakinen

Date Sujet#  Auteur
30 Oct 24 * Re: Supersedes sans cancel-key/cancel-lock19Olivier Miakinen
30 Oct 24 +* Re: Supersedes sans cancel-key/cancel-lock17M.V.
30 Oct 24 i+* Re: Supersedes sans cancel-key/cancel-lock7Eric M
30 Oct 24 ii`* Re: Supersedes sans cancel-key/cancel-lock6M.V.
30 Oct 24 ii `* Re: Supersedes sans cancel-key/cancel-lock5Eric M
30 Oct 24 ii  `* Re: Supersedes sans cancel-key/cancel-lock4M.V.
30 Oct 24 ii   `* Re: Supersedes sans cancel-key/cancel-lock3Eric M
30 Oct 24 ii    `* Re: Supersedes sans cancel-key/cancel-lock2Jean-Paul
30 Oct 24 ii     `- Re: Supersedes sans cancel-key/cancel-lock1Eric M
30 Oct 24 i`* Re: Supersedes sans cancel-key/cancel-lock9Olivier Miakinen
30 Oct 24 i `* Re: Supersedes sans cancel-key/cancel-lock8M.V.
30 Oct 24 i  +* Re: Supersedes sans cancel-key/cancel-lock4Eric M
30 Oct 24 i  i`* Re: Supersedes sans cancel-key/cancel-lock3M.V.
30 Oct 24 i  i `* Re: Supersedes sans cancel-key/cancel-lock2Eric M
31 Oct 24 i  i  `- Re: Supersedes sans cancel-key/cancel-lock1Zorro.
30 Oct 24 i  +- Re: Supersedes sans cancel-key/cancel-lock1Jean-Paul
30 Oct 24 i  `* Re: Supersedes sans cancel-key/cancel-lock2Olivier Miakinen
30 Oct 24 i   `- Re: Supersedes sans cancel-key/cancel-lock1Jean-Paul
30 Oct 24 `- Re: Supersedes sans cancel-key/cancel-lock1Jean-Paul

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal