요약

  • Netnews의Supersedes필드는 정확히 하나의 이전 게시물을Message-ID로 지정한다. 새 게시물은 여전히 별도로 식별되는 일반 게시물로 처리된다.
  • 이전 게시물의 철회는 취소(cancel)와 같은 방식으로 처리된다. 각 서빙 사이트는 요청을 인증·승인하고 자신의 로컬 조치를 적용한다. 한 사이트는 자신의 사본을 제거하는 반면 다른 사이트는 이를 보존할 수 있다.
  • Cancel-Lock과Cancel-Key는 이후 취소 및 대체 요청에 대해 더 강력한 증명을 제공했지만, 인증이 전역 삭제의 약속이 되지는 않았다.

두 서버, 하나의 수정판, 서로 다른 과거

수정된 기술 공지가 두 개의 Usenet 서빙 사이트에 도착하는 장면을 상상해 보자. 두 사이트 모두 수정판을 수용한다. 첫 번째 사이트에서는 철회 자격 증명이 검증되고 로컬 정책이 이전 공지를 정상 서비스에서 제거하는 것을 허용한다. 두 번째 사이트에서는 자격 증명을 검증할 수 없거나 정책이 조치를 거부하므로, 이전 게시물이 대체물 옆에 그대로 남는다.

수정판이 두 번째 사이트에서 실패한 것은 아니다. 그곳에도 첫 번째 사이트와 마찬가지로 존재한다. 달라지는 것은 독자에게 보이는 로컬 역사다. 한 서버는 수정판만 보여주고, 다른 서버는 두 버전을 모두 보여준다.

이 비대칭성이 바로Supersedes의 핵심이다. 이 필드는 모든 사본을 원자적으로 대체할 수 있는 분산 트랜잭션을 저자에게 부여하지 않았다. 대신 이전 게시물에 대한 요청을, 그 요청이 성공하지 않아도 자신의 생명에는 지장이 없는 새 게시물과 함께 하나의 패키지로 담았다.

먼저 등장한 것은 취소였다

보다 이른 기제는RFC 1036에 나타난다. 취소 제어 게시물은 대상을Message-ID로 지명했다. 해당 게시물을 취소할 수 있는 수신 시스템은 로컬에서 그렇게 하도록 되어 있었고, 조치를 수행할 수 없는 시스템이 그 때문에 어떤 보편적 저장소를 다시 쓸 권한을 얻지는 못했다.

승인 문제는 이미 존재했다. 사양은 취소 요청의Sender또는From을 대상 게시물의 해당 필드와 비교하고, 로컬 관리자가 직접 조치할 수 있도록도 허용했다. 이는 바로잡음과 파괴 행위를 구분하려는 시도였지만, 개방된 분산 시스템에서 헤더의 유사성은 약한 증거였다.

역사적 교훈은 취소가 삭제와 동등했다는 것이 아니다. 철회는 언제나 특정 사이트가 특정 저장된 사본에 대해 수행하는 작업이었다는 것이다. 배포는 권한을 판단해야 하는 지점을 여러 곳으로 늘렸다.

Supersedes는 변경 가능한 버전이 아니라 새 게시물을 추가했다

RFC 5536은 Netnews의Supersedes필드를 의도적으로 좁은 값, 즉 대체될 게시물을 식별하는 하나의Message-ID로 정의한다. 그 효과는 해당 대상에 대한 취소 요청이 즉시 처리되고, 그다음Supersedes필드를 제거한 새 게시물이 평소처럼 처리되는 것처럼 기술한다.

이 정식화는 매력적이지만 부정확한 모델을 막는다. 수정판은 이전 게시물의 기록에 들어가 본문을 덮어쓰지 않는다. 그것에는 자신만의Message-ID, 자신만의 헤더, 자신만의 네트워크 경로가 있다. 이 필드는 서로 다른 두 게시물을 연결하면서, 사이트들에게 그중 하나가 제공되는 방식을 바꾸도록 요청할 뿐이다.

순서도 중요하다. 철회는 대체물을 수용하기 위한 전제 조건이 아니다. 대체물은 전 아니면 아니오 방식의 수리 명령이 아니라 평범한 게시물로 남는다.

철회의 결정은 서빙 사이트의 몫이었다

RFC 5537은 이 구분을 명확히 한다.Supersedes자체는 제어 메시지가 아니지만, 지명된 이전 게시물을 철회하라는 요청은 취소와 동일한 규칙에 따라 인증되고 승인된다. 요청이 수용되면 사이트는 유효한 취소에 대해 수행했을 것과 같은 조치를 취한다.

그러나 요청이 수용되든 아니든, 새 게시물은 정상적으로 처리된다. 서버가 이전 사본을 보존한다는 이유만으로 수정판을 거부해서는 안 된다. 수정판을 수용한다고 해서 이전 사본이 사라졌다는 증명이 되는 것도 아니다.

이것이 “대체됨(replaced)”이 단일한 관측 가능한 상태가 아닌 이유다. 이는 두 게시물 식별자 간의 관계가 존재함을 의미할 수도 있고, 로컬 사용자 인터페이스가 새 게시물을 우선함을 의미할 수도 있으며, 특정 서버가 이전 게시물을 일반 검색에서 제거했음을 의미할 수도 있다. RFC들은 요청과 처리 경계를 정할 뿐, 모든 아카이브에 걸친 보편적 뷰를 정하지 않는다.

RFC 5537은 또한 약한 승인의 실질적 비용을 기록한다. 인증이 어렵고 악의적 취소가 매력적이었기 때문에, 역사적으로 많은 사이트가 취소 및 대체 요청을 무시했다. 게시 에이전트는 사용자가 타인의 게시물을 대체하려는 시도를 막아야 하지만, 모든 하류 사이트는 여전히 자신의 증거와 정책에 직면한다.

키는 증명을 개선했지만 주권을 만들지는 않았다

RFC 8315는 이 결정에 더 나은 암호학적 근거를 부여했다. 원본 게시물은Cancel-Lock을 담을 수 있다. 이후의 취소 또는 대체 게시물은 그 잠금값과 비교할 수 있는 도출값을 가진Cancel-Key를 제공한다. 이 기제는 사이트가 비슷해 보이는 주소만 믿는 대신, 원본 게시에 관련된 지식을 검증하게 해준다.

더 강한 인증은 중요한 남용 경로를 막지만, 네트워크를 하나의 데이터베이스로 합치지는 못한다. 일치하는 키는 이 기제를 구현한 사이트에서 승인을 뒷받침할 수 있다. 그러나 오프라인 아카이브가 사본을 삭제하거나, 인용을 무효화하거나, 게이트웨이 내보내기를 철회하거나, 모든 독립 운영자의 보존 정책을 강제할 수는 없다.

이 구분은 운영상으로 가치가 있다. 시스템은누가 철회를 요청했는지에 대해 더 확신할 수 있으면서,모든 사본이 어디로 갔는지에 대해서는 거짓 주장을 하지 않을 수 있다.

같은 단어가 모든 곳에서 같은 회수를 의미하지는 않았다

Supersedes라는 이름은 프로토콜 경계를 넘기도 했다. 인터넷 메일과 X.400 간의 매핑을 다루는RFC 2156은 하나 이상의 메시지 식별자를 담을 수 있는 메일 필드를 정의한다. RFC 5536은 자신의 Netnews 필드가 그 이메일 버전과는 아무런 관계가 없다고 경고한다.

IANA 메시지 헤더 레지스트리는 메일과 Netnews에 별도의 표준 항목을 두어 이 구분을 보존한다. 따라서 익숙한 필드 이름이 곧 Netnews의 철회 의미론을 메일함으로 가져오거나, 이메일 클라이언트·아카이브·뉴스 서버가 하나의 회수 모델을 공유한다고 가정할 허가는 아니다.

레지스트리 등재는 이름과 참조를 안정화한다. 그것이 현재의 지원 현황을 측정하거나, 사이트의 정책을 보증하거나, 삭제를 증명하지는 않는다.

수정판은 회수의 실패 속에서도 살아남았다

Supersedes는 소박하지만 오래 지속되는 문제를 해결했다. 즉, 정정을 게시하고 어떤 이전 게시물을 대체해야 하는지 표시하면서도, 정정의 전달이 완벽한 전역 정리에 종속되지 않도록 하는 문제였다. 그 아키텍처는 독립된 저장소를 가정하고 두 결과를 그에 따라 분리했다.

이 선택은 더 지저분한 역사를 남긴다. 독자는 두 버전을 모두 만날 수 있다. 아카이브는 서빙 사이트가 더 이상 보여주지 않는 것을 보존할 수 있다. 운영자는 “대체됨”이 연결됨을 의미하는지, 숨겨짐을 의미하는지, 로컬에서 철회됨을 의미하는지, 아니면 특정 코퍼스에서 실제로 부재함을 의미하는지 설명해야 한다.

하지만 대안인 허구—분산된 과거를 모든 곳에서 편집해 주는 버튼—은 더 나빴을 것이다. Netnews는 수정판을 새로운 사실로, 철회를 요청으로 만들었다. 정정된 기록은 이전 기록을 불러올 수 없을 때조차 앞으로 나아갈 수 있었다.