요약

  • NNTP는 전역적으로 고유한 Message-ID를, 뉴스그룹과 기사 번호로 구성된 서버 지역 키와 분리했습니다. 따라서 교차 게시된 글 하나가 여러 지역 번호를 가질 수 있지만 여러 글이 되지는 않습니다.
  • Xref는 그러한 그룹별 지역 위치를 서버 범위의 보관 접수증 하나에 모아, 읽기 소프트웨어가 동일한 교차 게시를 여러 번 처리하지 않도록 했습니다.
  • 서비스 서버는 일반적으로 들어온 Xref를 제거하고 자신의 것을 새로 기록했습니다. 이 재기록은 글이 훼손된 것이 아니라, 위치가 서버에 속하고 식별은 다른 곳에 있음을 보여주는 증거였습니다.

두 번째로 마주친 글

독자가 한 뉴스그룹에서 기사를 읽습니다. 나중에 구독 중인 다른 그룹에서 같은 기사가 다시 나타납니다. 제목과 본문은 같은데 기사 번호는 다릅니다. 이것은 중복일까요, 복사본일까요, 아니면 두 번째 게시일까요?

넷뉴스에서는 그 어느 결론도 필요하지 않습니다. 저자가 하나의 글을 두 그룹에 교차 게시했을 수 있습니다. 서버는 글 한 편만 저장하되 각 그룹 안에서 서로 다른 위치에 색인을 겁니다. 첫 번째 번호만 기억하는 클라이언트는 두 번째 좌표를 두 번째 기사로 잘못 볼 수 있습니다.

이것이 바로Xref가 읽기 소프트웨어가 풀도록 도왔던 문제입니다. 이 필드는 글에 또 다른 신원을 부여하지 않았습니다. 마지막으로 그 글을 처리한 서버의 보관 지도를 드러냈습니다. 하나의 서버 이름 뒤에, 그 서버가 글을 제공한 그룹과 위치자들이 따라옵니다.

이 구분은 잘못된 쪽 위에 분산 시스템을 세우기 전까지는 사소해 보입니다. 식별은 전파를 거쳐 살아남은 글이 어느 것인지 답합니다. 위치는 특정 서버가 현재 어디서 독자가 그 글을 회수할 수 있게 하는지 답합니다. 유즈넷은 둘 다 필요했고, 둘이 서로 뭉개지지 않기를 필요로 했습니다.

세 가지 키, 세 가지 범위

RFC 3977, 즉 2006년 NNTP 사양은 뉴스 기사를 저장하고 회수하는 데 쓰이는 세 종류의 키를 기술합니다. 첫째는 글에 대해 전역적으로 고유한 Message-ID입니다. 둘째는 뉴스그룹 이름과 그 그룹 안의 기사 번호를 결합한 것입니다. 셋째는 서버가 유지하는 도착 타임스탬프입니다.

그룹-번호 키에는 강한 지역 규칙이 있습니다. 한 서버의 한 그룹 안에서는 번호가 하나의 기사만 가리키고, 같은 그룹 안에서 하나의 기사가 두 개의 번호를 가질 수 없습니다. 그러나 교차 게시된 글은 각 그룹마다 하나의 키를 가질 수 있고, 그 번호들은 서로 다를 수 있습니다. 같은 그룹-번호 쌍이 서로 다른 서버에서 서로 다른 기사를 가리킬 수도 있습니다.

이것이 결정적인 경계입니다. 기사 번호는 작은 전역 식별자가 아닙니다. 서버의 그룹 뷰 안의 좌표입니다. 번호는 지역 도착 순서로 배정됩니다.GROUP명령은 저수위·고수위 표시와 대략적인 개수를 반환할 뿐, 그 사이의 모든 번호가 존재한다는 약속이 아닙니다. 기사는 삭제될 수 있고, 프로토콜 규칙 안에서는 이전에 저장된 기사가 이전 번호로 다시 복원될 수도 있습니다.

따라서 이 좌표는 서버에 속한 역사와 정책을 함께 나릅니다. 도착, 보존 기간, 만료, 중재, 복구 같은 것들입니다. 번호에 빈 구멍이 있다고 네트워크가 기사를 삭제했다는 증거는 되지 않습니다. 번호가 크다고 전역적으로 최신이라는 증거도 아닙니다. 새 서버에서 익숙한 번호를 본다고 식별이 확인되는 것도 아닙니다.

하나의 글, 여러 개의 선반

RFC 5536은 교차 게시(crossposting)를 하나의 글을 두 개 이상의 뉴스그룹에 게시하는 것으로 정의하며, 같은 텍스트를 별개의 기사로 게시하는 것과 구분합니다. 서버는 일반적으로 사본 하나만 저장합니다. 글은 Message-ID를 하나 가지지만, 그 주위로 그룹 색인은 여러 갈래로 퍼질 수 있습니다.

Xref는 그 갈래 퍼짐을 압축적으로 표현한 것입니다. 값은 그 필드를 만든 뉴스 서버의 식별자로 시작하고, 하나 이상의 위치가 뒤따릅니다. 각 위치는 뉴스그룹 이름을 기사 위치자와 결합합니다. 전통적인 NNTP 위치자는 십진수 기사 번호이지만, 이 필드는 구현 고유의 위치자를 허용합니다.

서버 이름은 장식이 아닙니다. 뒤따르는 위치자들이 어느 좌표계에 속하는지 소프트웨어에 알려 줍니다. 이 범위를 제거하면 겉보기에 같은 그룹 위치가 다른 곳의 다른 기사를 가리킬 수 있습니다. 범위를 유지하면 독자는 한 서버의 뷰 안에서 여러 위치가 결국 하나의 글로 돌아감을 알아볼 수 있습니다.

RFC 5536은 사용자 에이전트가 교차 게시된 글을 여러 번 처리하지 않기 위해 이 정보를 흔히 사용한다고 말합니다. 클라이언트는 한 그룹에서 기사를 보여 준 뒤 연결된 위치들을 '본 것'으로 표시할 수 있습니다. 이것은 단순한 편의가 아닙니다. 교차 게시의 의미를 지키는 일입니다. 하나의 기여가 여러 청중을 향할 수 있으면서, 여러 개의 독립된 기사로 계산되거나 다루어지지 않도록 합니다.

선언된 그룹과 보관된 그룹은 같은 주장이 아닙니다

Newsgroups필드는 글이 어디에 게시되었는지 말합니다.Xref는 마지막 서버가 글을 어디에 보관했는지 말합니다. RFC 5536은Xref의 위치가Newsgroups에 선언된 그룹과 달라도 된다고 명시적으로 허용합니다.

이 차이는 운영적으로 정직합니다. 서버는 모든 그룹을 운반하지 않을 수 있습니다. 지역 정책이 보관을 거부하거나 다른 곳으로 보낼 수 있습니다. 보존 기간이나 중재로 서비스 뷰가 바뀔 수 있습니다. 저자의 선언을 보관 접수증에 그대로 복사한다면 이러한 지역 결정들이 숨겨지고 맙니다.

따라서 두 필드는 서로 다른 질문에 답합니다.Newsgroups는 글의 선언된 배포와 함께 이동합니다.Xref는 지역 저장 뷰를 실체화합니다. 어느 쪽도 다른 쪽의 권위를 사칭하는 데 쓰여서는 안 됩니다.

그 접수증은 교체되기를 기다리는 것이었습니다

필드의 역사는 그 지역성을 유난히 분명하게 보여 줍니다. 1987년에 공개된RFC 1036은Xref를 호스트 이름과, 그 호스트의 스풀 디렉터리에서 가져온 그룹/메시지 번호 쌍들로 이루어진 것으로 기술했습니다. 이 정보는 지역 시스템에만 유용하며 전송되어서는 안 된다고 밝혔습니다. 그 예시는 같은 호스트의 두 그룹에서 한 기사가 서로 다른 두 번호에 놓이는 모습을 담고 있었습니다.

이후의 아키텍처는 접수증을 영구 식별자로 만들지 않으면서, 구성 요소들 사이에서 더 통제된 생애를 인정했습니다.RFC 5537은 중계 에이전트가 기존의Xref를 삭제하고 자신의 용도에 맞는 것을 추가할 수 있도록 합니다. 서비스 에이전트는 보낸 사이트의 위치자를 보존하는 특수 구성을 제외하고는 들어온 필드를 제거해야 하며, 그리고 — 보통 그렇게 합니다 — 저장 전에 새 것을 기록할 수 있습니다.

그 교체는 우연히 남겨진 허점이 아닙니다. 같은 RFC는 중계·서비스 에이전트가Path와Xref를 제외한 나머지에 대해서는 기사를 변경·삭제·재배열해서는 안 되고 본문을 수정해서는 안 된다고 규정합니다. 위치 메타데이터는 바뀌면서도 기사는 기사로 남습니다.

이것이 이 설계에서 가장 중요한 문장입니다. 산문이 아니라 아키텍처로 읽어도 마찬가지입니다. 지역 접수증은 보관 경계에서 다시 쓰일 수 있습니다. 그것은 서버의 보관 결정을 기록하는 것이지, 저자의 영속적인 기사를 기록하는 것이 아니기 때문입니다.

서버 이름은 범위이지 봉인이 아닙니다

이름 붙은 서버를 출처의 증거로 읽고 싶은 유혹이 있습니다. 사양은 그런 권한을 부여하지 않습니다. 이름은 소프트웨어에 위치들을 해석하는 방법을 알려 줄 뿐이며, 암호학적 서명도, 저자 검증도, 글의 여정에서 첫 서버였다는 증명도 아닙니다.

중계와 서비스 에이전트가 이 필드를 제거하고 재생성할 수 있다는 사실 자체가, 그것을 불변의 출처 기록으로 대하는 데 대한 경고입니다. 이 비인증 경계는 재기록 규칙과 인증 계약의 부재로부터 도출한 추론입니다.Xref는 서비스 뷰의 귀중한 증거이지만, 그 서버의 신뢰와 관찰 맥락 안에서만 그렇습니다.

현재IANA 메시지 헤더 레지스트리는Xref를 표준 넷뉴스 필드로 등록하고 RFC 5536을 가리킵니다. 이 레지스트리는Message-ID와Newsgroups도 별도로 등록합니다. 등록은 공통 어휘를 보존합니다. 그러나 글의 식별, 선언된 배포, 지역 위치를 하나의 권위로 합치지는 않습니다.

어딘가를 뜻한 번호

Xref의 성과는 더 강한 식별자를 발명한 것이 아니었습니다. 분산 읽기 시스템이 한 글이 여러 좌표를 가질 수 있고, 그 좌표들이 글을 바꾸지 않은 채 다음 서버에서 바뀔 수 있음을 인정하게 한 것이었습니다.

이 모형은 서로 대칭적인 두 가지 오류를 막습니다. 위치를 식별으로 대하면, 한 글이 여러 그룹을 차지하거나 서버 뷰 사이를 옮겨갈 때마다 중복이 생깁니다. 식별을 위치로 대하면, 전역적으로 이름 붙은 글이 반드시 하나의 보편적 주소를 가져야 한다고 가정하게 되지만 NNTP는 그런 약속을 한 적이 없습니다.

공식 근거는 현재 클라이언트들에서Xref가 얼마나 흔한지, 개별 공급자가 읽음 상태를 어떻게 구현하는지 보여 주지 않습니다. 특정 지역 기사가 사라진 이유를 설명할 수도 없습니다. 확립하는 것은 이 메커니즘의 범위입니다. Message-ID는 '어느 글인가'에 답하고,Xref는 '이 서버가 그 글을 어디에 보관했는가'에 답합니다. 그 절제가 곧 기능입니다.