요약

  • Date필드는 메시지가 실제 전송된 시점이 아니라 작성자가 메시지를 완성했고 발송 준비가 되었다고 판단한 시점을 가리킵니다.
  • Netnews 릴레이는 이미 본 Message-ID 이력에 상한을 두어야 합니다. 작성 시점의 오래됨과 네트워크상의 오래됨을 혼동하면 막 주입된 글까지 거부될 수 있습니다.
  • Injection-Date는 진입 지점의 관찰을 추가하면서Date를 바꾸지 않았습니다. 운영상의 정밀도는 높아졌지만, 이 시각이 작성자 증명, 정확성 증명, 보편적 도착 증명으로 변하지는 않았습니다.

하나의 월요일 안에 있는 두 금요일

어떤 사람이 출장 중에 글 한 편을 완성합니다. 사용 중인 소프트웨어는Date에 월요일을 기록한 뒤, 연결이 없어 그 글을 보존합니다. 금요일에야 포스팅 에이전트가 뉴스 서버에 도달합니다.

작성자에게 월요일은 정직한 답입니다. 글이 완성되었다고 선언된 순간이기 때문입니다. 릴레이 입장에서 이 값은, 이력에서 흔적이 삭제된 뒤 되돌아온 오래된 글의 값처럼 보일 수 있습니다. 한쪽은 연대기를 지키려 하고, 다른 한쪽은 flood-fill 배포를 반복으로부터 보호해야 합니다.

금요일로 다시 쓰면 통과가 쉬워질 수도 있지만, 최초의 사건을 위조하게 됩니다. 월요일을 유지하면 낡은 소프트웨어에서 'stale' 거부를 일으킬 수 있습니다. 이 충돌은 형식 논쟁이 아니었습니다. 같은 숫자에 붙은 두 결정에서 비롯된 것이었습니다.

Netnews의 답은 다른 쪽을 고치는 대신 시계를 하나 더 추가하는 것이었습니다.

Date가 약속했던 것

1987년의RFC 1036에서Date, 이전의Posted는 네트워크상 최초 게시일을 가리켰고, 전파 과정에서 변경되지 않아야 했습니다. 이 안정성 덕분에 중간 노드마다 자기 통과 시점에서 역사를 다시 시작하는 일이 막혔습니다.

이후RFC 5322는 완성과 전송을 더 분명하게 구분합니다. origination date는 작성자가 메시지가 완전하며 배포에 들어갈 준비가 되었다고 표시한 순간입니다. 오프라인 노트북의 예가 결정적입니다. 그 시각은 이후의 연결이 아니라 로컬 대기열에 속합니다.

이 의미론은Date에 문서적 가치를 부여합니다. 동시에 운영상의 한계도 드러냅니다. 작성자의 시계는 흐를 수 있고, 거짓말할 수 있고, 단순히 첫 전송보다 며칠 앞설 수도 있습니다. 정확하더라도 이 필드는 글이 Netnews에서 얼마나 오래 돌고 있는지는 말해 주지 않습니다.

이력은 끝없이 커질 수 없었습니다

Netnews에서는 여러 relaying agent와 serving agent가 같은 글을 주고받습니다.RFC 5537은 이들에게 이미 수락한 것을 기억하고 같은 글의 새 제안을 거부하도록 요구합니다. Message-ID가 키 역할을 합니다.

그러나 모든 식별자를 영원히 보관하는 것은 현실적이지 않습니다. 프로토콜은 컷오프 구간을 허용합니다. 더 오래된 글은 거부될 수 있고, 그에 해당하는 이력 항목도 사라질 수 있습니다. 날짜 검사가 그 글의 재등장을 막아 주기 때문입니다. 이 문서는 최소 7일을 Usenet의 관행으로 인용하면서도, 정상 전파보다 짧은 창은 한 번도 본 적 없는 글까지 지워버릴 수 있다고 경고합니다.

따라서 날짜는 그것이 중복이라는 사실을 증명하지 않습니다. 서버가 중복을 인식하기 위한 증거를 보관하는 기간을 한정할 뿐입니다. 창을 줄이면 자원은 절약되지만 오폐 refusal 위험이 커지고, 늘리면 느린 경로를 보호하지만 비용이 더 듭니다.

작성 시각만 있으면, 작성자가 만든 지연이 이 네트워크 계산을 오염시켰습니다.

작성자를 고치지 않는 진입 시각

RFC 5536은Injection-Date를 글이 네트워크에 주입된 날짜와 시각으로 정의합니다. 목적은 명시적입니다. 오래된 글을 탐지할 때 서버는 user agent가 작성 중에 기록한 시각 대신, 주입 시점에 추가된 시각을 사용할 수 있습니다.

이 필드는 주입 시점에 삽입되어야 합니다. 그러나 에이전트는 그 부재도 수락해야 합니다. 이전 소프트웨어는 이 필드를 알지 못했기 때문입니다. 그런 경우 규칙은Date로 되돌아갑니다. 이 호환성 덕분에 점진적 도입이 가능했지만, 이웃 시스템 간에 다른 판단이 나올 수 있습니다.

네트워크 진입이 역사를 다시 쓸 수 있다면 이 구분은 무의미해집니다. 그래서 RFC는Injection-Date를 추가할 때 이미 존재하는Date를 수정하는 것을 금지합니다. 시계가 잘 맞지 않으면 두 번째 값이 첫 번째보다 앞설 수 있다고까지 명시합니다. 음수 비교는 먼저 두 개의 시계를 가리키며, 시간 여행이 아닙니다.

새 이름은 규격 없이 쓰이던NNTP-Posting-Date를 대체했고, 그 필드는 폐기 대상이 되었습니다. 표준화는 공통의 기능을 만들었지만, 공통의 시계를 만들지는 못했습니다.

로컬에 남은 세 번째 시각

일상적인 이력 최적화에서 RFC 5537은 글의 'date'를, 존재하면Injection-Date, 아니면Date로 부릅니다. 릴레이와 서버는 과도하게 미래인 값과 자기가 선택한 컷오프 창을 검사할 때 이를 사용합니다.

또 다른 전략은 서버가 글을 처음 본 순간을 기준으로 흔적을 지웁니다. 설명된 스킴에서는, 미래 날짜에 허용된 여유를 흡수하기 위해 보관 기간이 컷오프보다 최소 24시간 길어야 합니다.

RFC 3977은 또 하나의 측정을 유지합니다. 각 서버는 자체 arrival timestamp를 갖고, 이 순서대로 글 번호를 부여합니다. 이 시간은 그 서버 관찰자만의 것입니다.

세 값은 세 명의 사실 소유자에 답합니다.

  • Date는 작성자의 완성 선언을 보존합니다.
  • Injection-Date는 Netnews로의 규정된 통과 지점을 표시합니다.
  • 로컬 도착 시각은 특정 서버의 수용을 표시합니다.

이들을 합치면 경로 지연이 작성자에게 귀속되거나, 작성 지연이 네트워크에 귀속됩니다.

여러 문, 하나의 나이

같은 글이 여러 injecting agent에 제공될 수 있었습니다. 예컨대 분리되어 있다고 여겨지는 네트워크를 이어 주거나 중복성을 얻기 위해서입니다. 목표는 경로가 다시 만났을 때 같은 Message-ID로 인식되는 하나의 글이었습니다.

그래서 RFC 5537은 Message-ID,Date,Injection-Date가 모든 제안에 존재하고 동일해야 한다고 요구합니다. 이미 주입된 글이 다른 진입을 위해 proto-article로 다시 변환될 때도 이 세 필드는 변경되지 않아야 합니다. 문마다 주입 시각을 갱신하면 같은 글에 인위적인 새 생명을 부여하여 루프 제거를 약화시킵니다.

이 필드는 단순한 '지금' 도장 이상입니다. 여러 진입이 같은 게시 행위를 대표할 때, 공유된 나이의 안정적인 일부가 됩니다.

호환성의 부채

낡은 서버들은 여전히Injection-Date를 무시하고Date로 오래됨을 판단합니다. RFC 5537은 그래서 전송 훨씬 전에 작성된 글이 새 필드가 있어도 잘 전파되지 않을 수 있음을 인정합니다.

posting agent는 작성이 하루 이상 지난 경우 전달 전에 주입 시각을 추가해야 하며, 다중 주입의 경우 반드시 추가해야 합니다. injecting agent 역시 너무 미래이거나 너무 과거인 값을 검사하고, 프로토콜 조건이 요구하면 현재 시각을 추가합니다. poster에 가까운 만큼, 거부를 유용하게 설명할 수도 있습니다.

그러나 이 어느 어느 의무도 낡은 피어를 바꾸지 못합니다. 전환은 두 종류의 증거를 같은 글에 실어 나르며, 그것이 어디서나 같은 판단을 내리지 않을 수 있음을 수용합니다.

표준 날짜는 증명서가 아닙니다

Injection-Date는 진입 지점에서 한 에이전트가 내놓은 시간적 진술입니다. 서명도, 작성자 증명도, 동기화 보증도 아닙니다. 이 필드는 모더레이터의 승인, 읽힌 시각, 이후의 모든 도착, 미래의 로컬 삭제를 알려 주지 않습니다.

IANA 메시지 헤더 레지스트리는 오늘날Injection-Date를 표준 Netnews 필드로 분류하고 RFC 5536을 참조합니다. 레지스트리는 어휘를 안정화합니다. 특정 값이나 각 서버의 배포를 인증하지는 않습니다.

이 역사적 혁신은 바로 이 절제에 있습니다. 작성자의 연대기는 계속 보였고, 네트워크는 자기 판단에 필요한 시각을 추가했으며, 각 서버는 여전히 자기 도착을 보관했습니다. 두 번째 날짜가 유용했던 것은 바로 첫 번째가 되기를 거부했기 때문입니다.