요약

  • RFC 1280은 실시간 목록이 아니라 공개 조정 스냅샷이었습니다. 이 문서는 독자에게 최신판을 확인하라고 안내하고, 이 판은 1992년 7월 31일 이후 사용을 금지했습니다.
  • STATE는 프로토콜의 표준화 성숙도를, STATUS는 한 부류의 시스템이 이를 어떻게 구현해야 하는지를 설명했습니다. 어느 라벨 하나만으로 배포나 운영 성공이 입증되지 않았습니다.

목록은 유용하기 때문에 오히려 위험해질 수 있습니다. 인터넷 표준화 과정에서 어떤 프로토콜의 위치를 확인하려던 운영자에게는 흩어진 RFC 문서들이 아니라 공통 참조 자료가 필요했습니다. RFC 1280은 바로 그 참조 자료를 제공하려 했습니다. 프로토콜 항목을 모으고, 표준화 단계를 설명하고, 요구 수준 라벨을 부여하며, 세부 사항을 다루는 문서들을 안내했습니다. 그러나 이 메모는 자신에게도 만료일을 명시했습니다. 1992년 3월판은 대략 분기마다 발행될 예정이며 7월 31일 이후에는 사용하지 말라고 규정했습니다.

이 만료일은 8월 1일에 모든 수록 프로토콜이 바뀐다는 주장이 아니었습니다. 그것은 디렉터리가 근거로 삼을 수 있는 한계를 표시한 것입니다. IAB는 살아 있는 조정 작업을 설명했고, 독자들은 네트워크 정보 센터(NIC)나 IANA에서 최신판을 받아 각 항목의 최근 변경 사항을 확인하도록 안내받았습니다. 9월에 발행된 RFC 1360이 이후 RFC 1280을 대체했습니다. 따라서 표준 목록은 기록 문서로서는 권위를 지니면서도, 명시된 시점 이후의 결정에 대해서는 틀릴 수 있었습니다.

이 목록은 혼동하기 쉬운 두 라벨도 구분했습니다. STATE는 성숙도를 의미했습니다. standard, draft standard, proposed standard, experimental, informational, historic. STATUS는 요구 수준을 의미했습니다. required, recommended, elective, limited use, not recommended. proposed standard 프로토콜이 elective일 수 있었고, informational 사양이 사용 권장으로 표시될 수도 있었습니다. 한 축은 사양이 과정에서 어디에 놓여 있는지를, 다른 축은 한 부류의 시스템이 이를 구현하거나 사용하도록 어느 정도 강하게 요구되는지를 설명했습니다.

어느 축도 조사 결과가 아니었습니다. RFC 1280은 일부 프로토콜이 IESG의 권고나 IAB의 비준 없이도 널리 구현되었다고 밝혔으며, 여기에는 커뮤니티에 중요한 벤더 프로토콜도 포함되었습니다. 반대로 "experimental" 라벨은 운영 배포를 보증하는 것이 아니라 연구 활동을 기록한 것입니다. 이 목록은 독자에게 배포 상태를 발행 상태에서 추론하지 말고, 표준 트랙 라벨에서 인기도를 추론하지 말라고 경고했습니다. 구현 근거, 상호운용성 시험, 운영 경험은 별도의 기록에 속했습니다.

이 메모는 인접 참조 문서들이 함께 갱신되지도 않는다고 경고했습니다. Assigned Numbers, Gateway Requirements, Host Requirements는 서로 다른 일정으로 개정되었으며, 서로 다를 경우 가장 최근 문서가 우선하도록 했습니다. RFC 1280은 자신을 각 프로토콜의 최신 RFC에 대한 안내서로 규정했지, 개별 사양을 대체하는 얼어붙은 문서가 아니라고 명시했습니다. 디렉터리는 근거를 정리했지만, 그 근거를 동시적인 것으로 만들지는 않았습니다.

1992년 표의 개별 항목보다 더 오래 남을 교훈이 여기에 있습니다. 상태 라벨에는 대상, 의미, 날짜가 필요합니다. RFC 1310은 표준화 과정을 설명하면서 주기적인 표준 RFC를 특정 사양에 대한 권위 있는 선언이라고 규정했습니다. RFC 1280은 자신의 만료를 명시하면서 그 스냅샷을 제공했습니다. 역사적 디렉터리 항목은 당시 IAB가 기록한 내용을 설명할 수 있지만, 프로토콜이 지금 무엇을 하는지, 운영자가 무엇을 설치했는지, 서비스가 작동했는지는 입증할 수 없습니다.

출처:RFC 1280;RFC 1310;RFC 1360.