RFC 1410: 기한이 있는 표준 목록과 IAB의 반송 권한

요약

1993년 3월의 공식 목록 RFC 1410은 그 판을 같은 해 7월 31일 뒤에는 사용하지 말라고 했다. 표준 상태를 담은 문서 자체에도 기한이 있었다.
단계가 올라갈 때마다 IESG의 권고와 IAB의 비준이 필요했다. IAB가 비준하지 않으면 제안은 IETF로 돌아갔고, 최소 대기기간과 독립 구현이 기술적 검증을 맡았다.

공식 목록의 첫 번째 약속은 영구성이 아니었다. 1993년 3월 RFC 1410은 독자에게 현재 판인지 확인하라고 했고, 7월 31일이 지나면 그 판을 쓰지 말라고 명시했다. 프로토콜의 상태는 움직인다. 한 번 인쇄된 표는 그 움직임을 자동으로 따라갈 수 없다.

표의 한 줄을 바꾸는 데에도 절차가 있었다. 개발의 대부분은 IETF 작업반에서 진행됐다. 성숙 단계는 Proposed Standard, Draft Standard, Standard였다. 각 승격에는 Internet Engineering Steering Group의 권고와 Internet Architecture Board의 비준이 따랐다. IAB가 비준을 거부하면 제안은 추가 작업을 위해 IETF로 돌아갔다. 먼저 권고한 쪽과 마지막에 비준하는 쪽을 분리한 것이다.

시간 역시 검토 장치였다. IAB는 Proposed에서 Draft까지 최소 6개월, Draft에서 Standard까지 최소 4개월을 두었다. 공동체가 검토할 시간을 벌기 위해서였다. 문서는 별도로 Draft가 큰 이의나 결함이 없으면 6개월 안에 Standard로 갈 가능성을 알리는 단계라고 설명했다. 6개월이라는 예상과 4개월이라는 하한은 서로 다른 문장이다. 어느 쪽도 날짜가 되면 저절로 승격된다는 뜻은 아니었다.

종이 위의 합의는 별개로 만든 코드 앞에서 시험받았다. IAB의 일반적 관행에 따르면 Proposed에서 Draft로 가려면 독립적인 구현이 최소 두 개 있어야 했다. 마지막 단계에는 대체로 운영 경험과 두 개 이상 구현 사이에서 입증된 상호운용성이 요구됐다. 같은 문서를 읽은 두 팀의 프로그램이 실제로 통신해야 비로소 사양의 빈틈이 드러난다.

판단이 어려우면 IAB는 IETF, IRTF, IAB의 전문가로 특별 검토위원회를 꾸려 구체적인 조치를 권고받을 수 있었다. 목록에는 바뀐 행을 표시하는 별표도 있었다. 새로 들어오거나 이동하거나 수정된 항목에 붙였다. 대체되거나 쓰이지 않게 된 프로토콜은 Historic으로 남겼다. 목록은 공식 지위뿐 아니라 지위가 바뀐 흔적도 보여줬다.

현재 RFC Editor 기록은 RFC 1410을 Historic으로 분류하고 RFC 1500이 이를 대체했다고 적는다. 앞선 RFC 1311 이야기는 RFC 번호와 STD 번호가 왜 다른지 다뤘다. 이번 기록이 묻는 것은 다른 권한이다. 누가 지위를 올릴 수 있었고, 누가 작업을 되돌릴 수 있었으며, 새 지위를 뒷받침한 작동 증거는 무엇이었나?

1993년의 답은 꽤 냉정했다. IESG가 권고하고 IAB가 비준하거나 돌려보내며, 독립 구현이 현장에서 말을 맞추고, 기다리는 동안 결함을 찾는다. 그렇게 적힌 공식 목록도 제 날짜가 지나면 퇴장한다. 권위에 기한을 적어 넣은 표준 목록이었다.