요약

  • NNTP 개요는 글마다 반복되던 헤더 조회를, 공통 코어와 선택적 꼬리가 공개된 순서를 지닌 탭 구분 요약 행으로 대체했다.
  • LIST OVERVIEW.FMT는 개요 데이터베이스가 대상 글 전체에 걸쳐 어떤 필드의 값이나 부재를 일관되게 기록하고 있을 때에만 그 필드를 광고할 수 있었다.
  • 스키마를 변경하는 동안 서버는 필드 저장을 멈추기 전에 그 필드를 먼저 철회해야 했고, 백필이나 만료가 일관성을 회복할 때까지 새 필드를 추가하지 않아야 했다.

두 탭 사이의 의미

개요 프로토콜에서 가장 작은 객체는 빈 셀이다. 전송 상에서는 두 개의 인접한 탭 문자에 지나지 않는다. 그러나 클라이언트는 그 공백이 정보인지 판단해야 한다.

서버가 모든 글에 대해 해당 열이 존재한다고 약속했다면, 공백은 대응하는 헤더나 메타데이터 항목이 없다는 뜻이다. 반대로 서버가 최신 글에만 필드를 인덱싱했다면 같은 공백은 "캡처하지 못했다"는 의미일 수도 있다. 이 둘은 정반대의 결론이다. 전자는 글에 대한 증거다. 후자는 불완전한 데이터베이스에 대한 증거다.

RFC 3977은 이 구분을 명시적으로 만들었다. 어떤 필드에 대해 모든 해당 글에서 그 필드의 내용이나 부재를 기록하고 있을 때 개요 데이터베이스는 일관되다. 일부 글에는 필드가 있으면서 그 필드를 지녔던 다른 글에는 기록하지 못한다면 데이터베이스는 일관되지 않다.LIST OVERVIEW.FMT가 광고하는 스키마는 일관되지 않거나 저장되지 않은 필드를 주장해서는 안 된다.

테이블 이전, 한 번에 한 헤더

원래의RFC 977은 리더에게HEAD를 제공했다. Message-ID나 서버 로컬 번호로 글을 선택하면 그 헤더를 받는다. 명령은 정밀했지만, 큰 뉴스그룹의 제목·작성자·날짜·스레드 참조를 알아내려면 글 단위 연산을 반복해야 했다.

개요 작업은 조회의 단위를 바꿨다.RFC 2980은XOVER를 문서화했는데, 이는 요청된 번호 범위에 존재하는 모든 글마다 하나의 압축 행을 돌려주었다. 행은 글 번호로 시작해 제목, 작성자, 날짜, Message-ID, 참조, 바이트 수, 줄 수가 이어졌다. 선택 필드가 그 뒤를 따를 수 있었다.

절약은 사전 계산과 배치 처리에서 나왔다. 대화 목록을 그리기 위해 모든 전체 헤더 블록이 필요했던 것은 아니었다. 그러나 압축 행은 레이블을 없앤다. 값이 위치로 축소되면 양쪽 모두가 모든 위치가 무엇을 의미하는지 정확히 합의해야 한다.

고정 코어와 선언된 꼬리

RFC 3977은 이 명령을OVER로 표준화했다. 처음 여덟 필드는 고정이다: 글 번호 또는 0, Subject, From, Date, Message-ID, References,:bytes,:lines. 탭이 필드를 구분한다. 내부 필드가 빠져도 인접한 탭으로 자리를 유지하며, 끝의 빈 필드는 생략할 수 있다.

값은 문법을 보호하기 위해 정규화된다. 접힌 헤더 행은 펼쳐지고, 값 안의 탭은 공백으로 바뀐다. 그렇지 않으면 내용이 구분자인 것처럼 위장해 뒤따르는 모든 열을 밀어낼 수 있다.

확장은 추측을 요구하지 않았다.LIST OVERVIEW.FMT는OVER가 사용하는 순서대로 한 줄에 하나의 필드 설명을 돌려주었다. 처음 일곱 설명은 두 번째부터 여덟 번째 필드에 대응했다. 이후 항목은 추가 메타데이터를 명명하거나,:full접미사로 돌려지는 헤더가 헤더 이름을 유지한다고 밝혔다. 코어는 안정적으로 유지되고 꼬리는 명시적 계약 아래에서 늘어날 수 있었다.

스키마는 역사에 대한 주장이었다

핵심 혁신은 단순히 열 이름을 공개한 것이 아니었다. 그 이름을 그 순간 데이터베이스가 일관되게 지원할 수 있는 범위로 제한한 것이다.

운영자가 오늘부터 추가 헤더를 인덱싱하기로 결정했다고 하자. 새 글은 즉시 그 열을 채울 수 있지만, 서버가 개요 레코드를 다시 만들지 않는 한 오래된 글은 그렇지 못하다. 즉시 열을 광고하면 빈 셀의 의미가 모호해진다. 오래된 행의 누락된 값이 그 글에 헤더가 없었다는 뜻인지, 아무도 백필하지 않았다는 뜻인지 알 수 없다.

그래서 RFC 3977은 스키마 마이그레이션을 두 단계의 행위로 만들었다. 어떤 필드의 저장이 멈추기 전에 반드시LIST OVERVIEW.FMT에서 제거되어야 한다. 새 필드는 데이터베이스가 다시 일관된 이후에만 광고된 형식에 들어와야 한다 — 재구성이 끝난 후이거나, 오래된 글이 만료되어 남은 모든 행이 새 규칙 아래에서 만들어졌을 때이다.

형식은 하나의 세션 안에서도 바뀔 수 있다. 어제의 스키마를 영구적인 것으로 다루는 클라이언트는 오늘의 행을 잘못 읽을 수 있다. 기능과 형식의 발견은 현재 서버 상태에 대한 관찰이지, 영원한 문서가 아니다.

열을 보류하는 것이 공백의 진실을 지켰다

이 규칙은 보수적으로 보인다. 서버가 어떤 값을 가지고 있더라도 그 필드를 열로 노출하지 않을 수 있기 때문이다. 그러나 불완전한 지식을 보류하는 것이 모든 빈 슬롯의 의미적 가치를 보호한다. 필드가 한 번 광고되면 RFC 3977은 클라이언트가 빈 셀을 "그 글에 해당 헤더나 메타데이터 항목이 없었다"는 추론의 근거로 삼을 수 있도록 한다.

이렇게 프로토콜은 데이터 가용성과 증거적 권위를 분리했다. 부분적인 값을 가진 것만으로는 열 계약을 발표할 수 없었다. 서버는 먼저 동일한 캡처 규칙이 대상 컬렉션 전체를 덮고 있음을 알아야 했다.

그렇기에LIST OVERVIEW.FMT에서의 누락은 글에서의 누락과 동등하지 않다. 전자는 인덱스가 그 필드에 대해 일관된 약속을 하지 않는다는 뜻이다. 후자는 약속이 존재한 이후에야 알 수 있다.

메타데이터는 작성된 헤더가 아니었다

개요는 서버가 계산한 메타데이터와 글 본문 내용을 구분했다.:bytes와:lines는 콜론으로 시작하며, 글 안에 담겨 들어온 비슷한 이름의 헤더에서는 신뢰해서는 안 된다. 서버가 계산한다.

그럼에도 권위에는 경계가 있다. RFC 3977은:bytes가 글을 어떻게 세는지 규정하면서도 역사적 변형을 기록하고 클라이언트가 완전한 정확성에 의존하지 말라고 한다.:lines는 더 엄격한 본문 줄 정의를 가진다. 필드는 명확한 출처를 가지면서도 측정의 한계를 지닐 수 있다.

범위 출력에도 경계가 있다. 존재하는 행은 글 번호로 정렬되지만, 제거된 글은 돌려주지 않아야 하며 빈 자리가 남을 수 있다.OVER는 서버가 보고할 수 있는 것을 요약할 뿐, 만료된 본문을 재현하거나 모든 번호가 존재함을 증명하지 않는다.

IANA NNTP 파라미터 레지스트리는OVER를 표준화된 개요 지원 기능으로 기록한다. 이는 상호운용 가능한 신호이지, 현재 배포나 성능 보장이 아니다.

빠르기는 더 좁은 약속을 요구했다

개요 데이터베이스는 반복되는 파싱을 공유된 서버 측 인덱스로 옮겨 뉴스 읽기를 실용적으로 만들었다. 그러나 모든 공백이 글의 부재와 인덱싱 실패를 뒤섞인다면 가장 빠른 테이블은 위험했을 것이다.

NNTP는 스키마가 자신의 한계를 고백하게 만들어 이 문제를 해결했다. 불완전한 마이그레이션 동안 서버는 더 적게 광고했다. 일관성이 돌아온 뒤에 더 많이 약속할 수 있었다. 공백 필드가 신뢰할 수 있게 된 이유는 공백이 스스로를 설명해서가 아니라, 그 열이 부재를 주장할 권리를 이미 허를 수 있었기 때문이다.

출처