요약

  • Distribution은Newsgroups옆에 전파 조건을 추가했습니다. 일반적인 릴레이 경로는 주제와, 필드가 존재할 경우 요청된 범위 중 최소 하나를 모두 일치시키는 것이 기대되었습니다.
  • 예약 값local은 로컬 구성으로 정의되는 로컬 사이트를 의미했습니다. 선택적 서버 힌트가 클라이언트의 이름 선택을 도울 수는 있었지만, 보편적인 경계를 담은 이식 가능한 토큰은 없었습니다.
  • RFC 5537은 이 한계를 명시했습니다. 제한적인 배포는 모든 수신 사이트의 협조에 의존하며, 플러드 필드 방식은 기사를 외부로 내보내는 어떤 게이트웨이든 찾아낼 수 있었습니다. 범위는 유용한 정책이지 기밀 유지가 아니었습니다.

같은 단어, 서로 다른 두 경계

Distribution필드가local이라고 적힌 기사를 받는 인접한 두 뉴스 사이트를 상상해 보십시오. 바이트는 동일하고 의도는 명확해 보입니다. 그러나 한 사이트의 로컬 영역은 단일 기기일 수 있고, 다른 사이트는 기관 단위 클러스터일 수 있으며, 세 번째 릴레이는 그 이름을 전혀 인식하지 못할 수도 있습니다.

토큰 자체 어디에도 이 경계들을 그려 놓지 않습니다. 어떤 피어가 로컬 교환에 속하는지, 그 피어들이 어떤 배포 범위를 보내고 받는지는 각 사이트가 스스로 판단해야 합니다. 헤더는 그것을 해석할 권한보다 더 멀리 이동할 수 있습니다.

이것이 Netnews 배포 통제의 중심에 있는 작은 역설입니다. 복제되는 네트워크는 모든 게시 클라이언트를 라우팅 관리자로 만들지 않으면서 더 좁은 독자층을 표현할 이식 가능한 방법이 필요했습니다. 그 결과는 접근 통제 목록이 아니라, 자율적인 릴레이가 자신의 구성과 대조해 볼 수 있는 요청이었습니다.

뉴스그룹 옆의 두 번째 조건

이 초기 메커니즘은RFC 850에 등장합니다. 그 예시는 의도적으로 평범합니다. 광범위한 이름의 그룹에 올라가지만 뉴저지 주 독자만을 겨냥한 중고차 판매 공지입니다.Distribution은 기존 뉴스그룹 도달 범위를 넓히는 것이 아니라 제한하기 위한 것이었습니다.

RFC 1036은 두 축을 더 분명하게 만들었습니다. 사용자 구독은 여전히Newsgroups가 결정했습니다. 릴레이 선택은 일반적으로 수신 사이트가 이름이 지정된 그룹 중 최소 하나를 수용하고, 추가 필드가 존재하면 지정된 배포 범위 중 최소 하나도 일치시켜야 했습니다. 주제와 전파 범위는 별개의 검사였습니다.

이 분리는 흔한 범주 오류를 막았습니다.Newsgroups가 기사가 얼마나 멀리 이동해야 하는지를 반드시 말하지 않았고,Distribution이 독자가 참여한 대화를 결정하지도 않았습니다. 광범위하게 복제되는 그룹이 지리적으로 좁은 공지를 실을 수 있고, 로컬 그룹은 원격 사이트가 그 이름을 운반하지 않기 때문에 이미 제한되어 있을 수도 있습니다. 두 메커니즘은 서로를 보강하면서도 서로 바꿔 쓸 수는 없었습니다.

경계는 의도적으로 부재했다

RFC 5536은 이후Distribution을 전파에 대한 지리적·조직적 제한으로 정의했습니다. 문법은 배포 이름의 목록을 담았을 뿐, 토폴로지나 구성원 목록, 경로를 담지 않았습니다.

두 개의 예약 이름이 이 설계를 드러냅니다.world는 무제한 배포를 의미하며, 그 필드가 없는 것 자체가 이미 이 기본값을 함축하므로 보통 생략해야 합니다.local은 로컬 사이트로의 배포를 의미하지만, 그 로컬 사이트는 로컬 소프트웨어 구성으로 정의됩니다.

두 번째 정의가 겉보기보다 더 중요합니다. 이는 발신자가 타인의 로컬 영역 크기를 선언하지 못하게 합니다. 클라이언트는local이라고 쓸 수 있지만, 그것이 한 호스트를 뜻하는지, 하나의 캠퍼스를 뜻하는지, 혹은 다른 형태의 유한 교환을 뜻하는지는 오직 그 사이트의 운영 구성만이 말할 수 있습니다.

다른 이름은 대소문자를 구분하지 않습니다.All은 금지되며, 두 글자 국가 코드를 제외하면 이름은 보통 세 글자 이상이어야 합니다. 이러한 문법 규칙은 모호성을 줄이지만, 모든 조직적 경계를 등록하는 전 세계적 레지스트리를 만들지는 않습니다. 인식 가능한 철자가 보편적 권위는 아닙니다.

서버는 제안할 수는 있었지만 입법할 수는 없었다

게시 소프트웨어는 유용한 값을 고르는 데 도움이 필요했습니다. 이에RFC 3977은 선택적인LIST DISTRIB.PATS기능을 설명합니다. 서버는 뉴스그룹 패턴을 제안된Distribution내용에 매핑하는 가중 규칙을 공개할 수 있고, 더 구체적이고 가중치가 높은 규칙이 일반 규칙보다 우선할 수 있습니다.

그 예시 구조 자체가 시사적입니다. 일부 서버가 유지하는 목록이며, 클라이언트가 사용할 수 있을 뿐입니다. 게시 지점에 가장 가까운 서버는 그 제안을 전역적 진실로 가장하지 않고도 자신의 이름 관행을 설명할 수 있습니다.

이는 실행을 사용자 인터페이스 편의와 분리합니다. 메뉴는 적절한 범위를 추천할 수 있습니다. 그러나 그 추천이 다음 릴레이를 구성하거나, 피어링 합의를 성립시키거나, 모든 다운스트림 사이트가 같은 이름을 인식함을 보장하지는 않습니다. 조언은 게시자가 요청을 만들도록 돕지만, 네트워크 경계가 되지는 않습니다.

모든 홉은 여전히 자체 판단을 내렸다

RFC 5537은 실질적 검사를 릴레이 에이전트에 둡니다. 송신 및 수신 에이전트가 최소 하나의 일치하는 뉴스그룹, 그리고Distribution이 존재하면 최소 하나의 일치하는 배포 범위에 대해 구성되어 있지 않다면 기사를 릴레이해서는 안 됩니다.

이 규칙은 양방향입니다. 기사는 이름을 제공하지만, 송신 피어는 그 이름을 제공하도록, 수신 피어는 수신하도록 구성되어야 합니다. 문법도 게시자도 그 관계를 만들어 낼 수 없습니다.

이는 독립적인 사이트들로 조립된 네트워크에 실용적인 적합이었습니다. 대학, 기업 또는 지역 교환은 명시적 피어 정책을 통해 더 작은 전파 영역을 만들 수 있었습니다. 그 밖의 사이트들은 모든 레이블을 중앙 서비스가 판정할 필요가 없었습니다. 대가는 정확성이 수많은 구성 안에 흩어져 살고, 같은 기사가 서로 다른 경계에서 서로 다른 판단을 만날 수 있다는 것이었습니다.

범위는 대화의 일부가 될 수 있었다

가장 초기 사양조차 후속 글은 원문 기사의 배포 범위를 기본값으로 상속해야 한다고 말했습니다. RFC 5537은 이 원칙을 유지합니다. 게시 에이전트는 후속 글을 작성할 때Distribution을 상속해야 합니다.

상속이 중요한 이유는 답글이 모든 문장을 인용하지 않더라도 원래 대화를 드러낼 수 있기 때문입니다. 이전 범위를 기본으로 유지하면 의도치 않은 확대를 줄입니다. 또한 운영자가 기사가 왜 한 릴레이 영역이 아닌 다른 영역에 들어갔는지 설명할 수 있는 능력을 보존합니다.

그러나 상속은 불변의 봉인이 아니라 기본값입니다. 게시자는 이를 무시할 수 있습니다. RFC 850은 더 넓은 배포가 적절할 때 답글의 범위를 좁히거나 이전에 제한된 토론을 확장하는 것을 명시적으로 상정했습니다. 다음 저자는 새로운 공개 결정을 소유합니다. 범위 레이블은 하나의 기사에 속할 뿐, 모든 후손을 영구히 지배하지 않습니다.

플러드 필드는 요청과 경계의 차이를 찾아냈다

보안 경계는 완곡함 없이 서술됩니다. RFC 5537은 제한된 배포를 위한 기사가 모든 수신 사이트의 선의에 의존한다고 말합니다.Distribution과Archive는 배포 또는 보존에 대한 제한을 요청할 수 있지만, 프로토콜이 그것을 강제할 수는 없습니다.

이 한계는 파서 결함이 아니라 구조적입니다. 수신 사이트는 내용을 복제하거나, 피어를 잘못 구성하거나, 요청을 고의로 무시하거나, 다른 메커니즘이 기사를 다시 유입하도록 허용할 수 있습니다. Netnews 플러드 필드는 제한된 서브넷 밖으로 나가는 어떤 경로든 찾아내는 데 특히 능숙합니다.

권고되는 대응은 토폴로지와 관리입니다. 누출 통제가 필요한 조직은 외부 뉴스 교환을 위해 소수의 게이트웨이를 사용해야 합니다. 진짜 경계는 트래픽이 통과할 수 있는 지점, 그 통과점을 운영하는 주체, 그리고 그들이 강제하는 규칙에 나타납니다. 헤더는 의도된 처리에 대한 유용한 증거로 남지만, 그 통제를 대체할 수는 없습니다.

등록은 이름을 안정시켰을 뿐, 약속이 아니었다

현재IANA 메시지 헤더 레지스트리는Distribution을 RFC 5536을 참조로 하는 표준 Netnews 필드로 등재합니다. 구현체들은 필드 이름과 문법에 합의할 수 있습니다.

그러나 등록이 사이트 고유 토큰의 의미를 인증하거나, 릴레이가 그것을 존중했음을 증명하거나, 유출된 사본을 무효로 만들지는 않습니다. 표준들은 현재의 배포 현황, 어떤 공급자의 인식 이름표, 특정 게이트웨이 설계의 효과를 확립하지도 않습니다.

역사적 성취는 더 절제되어 있었습니다. Usenet은 모든 커뮤니티를 관할하는 중앙 지도 제작자를 만들지 않으면서 원하는 도달 범위를 명시적으로 만들었습니다. 사이트들이 운영 자율성을 보존하면서 일상적 전파를 조율하도록 허용한 것입니다. 이 필드는 모두가 그 권한의 끝을 기억할 때 작동했습니다. 요청된 범위를 진술할 수는 있었지만, 경계 자체는 다른 곳에 살아야 했습니다.