Кратко

  • Netnews-поле Supersedes указывает ровно одну прежнюю статью по Message-ID; исправление остаётся новой обычной статьёй с собственной идентичностью.
  • Снятие предшественницы проходит как cancel: каждый обслуживающий сайт отдельно проверяет полномочия и действует только со своей копией. Два сайта могут принять исправление, но сохранить разную видимую историю.
  • Cancel-Lock и Cancel-Key усилили доказательство права на отзыв, не создав гарантии удаления из всех архивов и шлюзов.

Новая версия совпала, прошлое — нет

Два новостных сервера получают исправленный материал и оба публикуют его. Первый подтверждает данные для отзыва и перестаёт выдавать старую статью. Второй не может подтвердить запрос либо не исполняет его по локальным правилам, поэтому оставляет обе версии.

Исправление успешно в обоих местах. Различается судьба предшественницы. Отсюда следует важное ограничение языка: «заменена» может означать зарегистрированную связь, предпочтение интерфейса или фактическое снятие конкретной копии, но не обязательно исчезновение отовсюду.

Supersedes позволял поправке двигаться вперёд, не ставя её в зависимость от недостижимого единодушия всех хранителей прошлого.

Cancel изначально действовал на локальную копию

В RFC 1036 управляющая статья cancel называет цель через Message-ID. Получившая её система снимает ту копию, которой распоряжается, если умеет выполнить действие. Единого центрального экземпляра, изменение которого переписало бы все реплики, не существовало.

Слабым местом была авторизация. Раннее правило сравнивало Sender или From запроса и цели, допуская также полномочия администратора сайта. Похожий заголовок плохо доказывал контроль над исходной публикацией и создавал пространство для чужого удаления.

Распределение копий означало распределение решений. Требовалось не только точно назвать статью, но и убедить каждого независимого оператора в праве на действие.

Supersedes создавал преемницу, а не правил старую запись

RFC 5536 ограничивает Netnews-значение Supersedes одним Message-ID. Его эффект описан как обработка cancel для указанной цели, за которой немедленно следует обычная обработка новой статьи, словно поле уже удалено.

Редакция не занимает идентичность предшественницы и не меняет её текст на месте. У неё собственный Message-ID, заголовки и путь распространения. Поле лишь устанавливает отношение между двумя самостоятельными публикациями и просит совершить отдельное действие над прежней.

Кроме того, неудача отзыва не должна блокировать новую статью. Сервер может хранить старую и всё равно нормально принять исправление.

Каждый сайт сохранял решение за собой

RFC 5537 уточняет: Supersedes само по себе не является управляющим сообщением, однако его просьба о снятии проходит ту же аутентификацию и авторизацию, что cancel. Если сайт её признаёт, он выполняет аналогичное локальное действие.

Независимо от результата новая статья обрабатывается обычно. Принятие редакции не подтверждает удаления старой, а сохранение старой не доказывает отказа от исправления.

Историческая практика усилила эту границу. Многие сайты игнорировали cancel и supersede, потому что проверка была трудной, а злоупотребление позволяло убирать чужие тексты. Клиент публикации должен запрещать пользователю заменять не принадлежащую ему статью, но downstream-сайты всё равно оценивают запрос самостоятельно.

Криптографический ключ улучшил проверку, а не охват

RFC 8315 ввела Cancel-Lock и Cancel-Key. Исходная статья несёт значение lock, а позднейший cancel или superseding article предъявляет ключ, производное от которого сравнивается с lock. Узел получает доказательство знания, связанного с первоначальной публикацией, вместо доверия к похожему адресу.

Такой ключ отвечает на вопрос о заявителе, но не перечисляет все места хранения. Он не приказывает независимому архиву, не возвращает экспорт шлюза, не стирает цитаты и не заменяет локальную политику. Совпадение повышает уверенность конкретного оператора, не давая ему власти над сетью.

Корректно сказать: «запрос подтверждён и выполнен этим сервисом». Нельзя подменять это фразой: «статья удалена из Интернета».

Одноимённое поле почты имело другой договор

RFC 2156, посвящённая преобразованию Internet Mail и X.400, также определяет Supersedes, причём со списком из одного или нескольких идентификаторов. RFC 5536 прямо отделяет от него одноцелевой вариант Netnews.

Реестр заголовков сообщений IANA содержит отдельные стандартные записи для mail и netnews. Совпадение имени не создаёт общей функции отзыва для почтового ящика, news-сервера и архива.

Реестр закрепляет имя и нормативную ссылку, но не подтверждает современную поддержку и не сообщает судьбу конкретных копий.

Исправление добавляло новый факт к неровной истории

После Supersedes один читатель мог увидеть только редакцию, другой — обе версии, а архив — сохранить материал, уже скрытый обычным сервером. Такая неоднородность честнее заявления о тотальном удалении без наблюдаемых доказательств.

Необходимо различать связь замещения, скрытие интерфейсом, снятие из определённого хранилища и проверенное отсутствие в конкретном корпусе. Ни одно состояние автоматически не влечёт остальные.

Механизм не давал автору права переписать распределённое прошлое. Он давал исправлению отдельную идентичность и путь вперёд, а просьбу об отзыве ограничивал полномочиями хранителя. Предшественницу нельзя было вернуть отовсюду, но это не мешало новой версии стать частью истории.