요약

  • RFC 825는 RFC가 자신의 의도를 명시하도록 요구했습니다. 동일한 번호 체계가 사양, 논의, 정보, 상태 변경 메모, 회의 보고서를 모두 담고 있었기 때문입니다. 번호는 문서의 위치를 알려줄 뿐, 보편적인 권위 수준을 식별해 주지는 않았습니다.
  • 공개 파일, 메일링 리스트 공지, 절제된 ASCII 페이지 형식은 기록을 여러 장비에서 이동 가능하게 만들었습니다. 쉬운 검색은 접근성을 넓혔지만 합의, 채택, 적합성을 만들어 내지는 못했습니다.
  • 이후 문서들은 하나의 아카이브를 유지하면서 문서 정체성과 표준 정체성을 분리했습니다. 따라서 신뢰할 수 있는 인용에는 RFC 번호와 함께 상태, 날짜, 스트림 또는 절차, 대체 관계, 구현 증거가 필요합니다.

빠진 필드가 번호보다 더 중요했다

가상의 조달 조항이 틀린 이유는 RFC 825가 생소해서가 아닙니다. "준수(compliant)"의 대상이 정의되지 않았기 때문입니다. RFC 825는 제품이 구현할 네트워크 프로토콜을 명시하지 않았습니다. RFC 자체에 대한 지침을 제공했습니다. 문서 번호는 참조를 정확하게 만들 수 있지만, 그 참조 위에 세운 주장이 거짓이 되는 것을 막지는 못합니다.

RFC 825는 실용적인 사실에서 출발했습니다. 사람들은 서로 다른 이유로 RFC를 발표했습니다: 정보를 유통하기 위해, 논의를 시작하거나 이어가기 위해, 또는 프로토콜을 명시하기 위해. 따라서 하나의 표지와 하나의 번호 체계는 서로 다른 결과를 낳는 행위들을 함께 담게 되었습니다. 이 체계는 독자에게 어떤 행위가 의도되었는지 알려주는 필드를 필요로 했습니다.

이 메모는 그 선언을 표지 페이지 또는 첫째나 둘째 단락에 두도록 요구했습니다. 정해진 한 문구를 그대로 요구하지는 않았습니다. 일반적 의도가 명확하면 된다고 요구했습니다. 이 구분이 중요했습니다: 공통 규칙은 공개 요구 사항이었지, 모든 기고를 동일한 문체로 몰아넣으려는 시도가 아니었습니다.

다섯 가지 형식은 선반을 나누지 않고 일을 나누었다

RFC 825는 다섯 가지 예를 제공했습니다.Specification은 메모가 ARPA 인터넷 커뮤니티를 위한 표준을 명시하며 호스트가 이를 채택하고 구현해야 한다고 선언했습니다.Discussion은 문제와 가능한 해법에 주의를 환기하면서, 어느 것도 아직 표준으로 의도되지 않았음을 명시적으로 밝혔습니다. 합의는 나중에 형성될 수 있었습니다; 발표 자체는 그것이 이미 존재한다고 주장하지 않았습니다.

Information메모는 인터넷 연구 프로그램의 중심이 아니더라도 흥미로울 수 있는 자료에 대한 반응을 요청했습니다.Status메모는 발표 시점 기준으로 프로젝트를 정확히 기술하면서, 정보가 바뀔 수 있고 이후 RFC가 그 변화를 반영할 수 있음을 경고했습니다.Report는 회의를 기록했습니다: 중요한 결정, 선택적 프로토콜 기능의 제한 또는 확장, 정책 질문, 기술 주제, 아직 끝나지 않은 작업.

이 범주들은 단지 문체적 장르가 아니었습니다. 증거적 무게를 배분했습니다. 논의는 아이디어가 공적 검토에 들어갔음을 증명할 뿐, 동료들이 수용했음을 증명하지 않았습니다. 상태 메모는 날짜가 찍힌 스냅샷을 제공했지 영구적 사실이 아니었습니다. 회의 보고서는 결정이 기록되었음을 증명할 수 있지만, 그 결정의 범위는 여전히 회의와 그 뒤의 절차에 의존했습니다. 사양은 더 강한 주장을 했지만, 구현과 채택은 여전히 별개의 증거였습니다.

모든 범주를 하나의 체계에 두는 것은 공통 검색 경로를 보존했습니다. 의도를 눈에 보이게 유지하는 것이 그 공통 경로가 범주들의 권위를 평평하게 만들지 못하게 했습니다.

구식 페이지는 호환성 계층이었다

RFC는 공개 접근 파일로 보관되었습니다. 배포 목록으로 보내는 짧은 메시지가 메모를 이용할 수 있음을 알렸습니다. 관심 있는 사람들은 파일을 복사해 자신의 장비에서 인쇄하거나 표시했습니다. 이 배포 모델은 문서가 폰트, 화면, 프린터, 텍스트 소프트웨어를 공유하지 않는 기기들에서 살아남는 데 의존했습니다.

RFC 825는 좁은 표현 계약으로 응답했습니다: ASCII 문자; 각 페이지마다 폼 피드가 뒤따르는 58줄 이하; 각 줄마다 캐리지 리턴과 라인 피드가 뒤따르는 72자 이하; 겹쳐 치기나 밑줄 금지. 헤더, 푸터, 페이지 번호, 들여쓰기 모두 이 한도 안에 포함되었습니다.

이 제약들은 전송 목적에서 분리되어 보면 구식처럼 보일 수 있습니다. 그러나 맥락 안에서 이는 접근 메커니즘이었습니다. 아카이브는 특정 워드 프로세서나 디스플레이를 요구하지 않았습니다. 누구든지 안정적인 파일을 검색해 서로 다른 장비에서 거의 같은 기록을 볼 수 있었습니다.

휴대 가능성은 메모의 의도를 바꾸지 않았습니다. ASCII가 Information 노트를 표준으로 만들지는 않았습니다. 배포 목록 공지가 투표가 되지는 않았습니다. 공개 접근이 누군가 제안을 구현했다는 증명이 되지는 않았습니다. 형식은 증거가 이동하게 만들었을 뿐, 증거가 무엇을 의미하는지 결정하지 않았습니다.

일련번호는 문서를 식별했지 프로토콜 상태를 식별하지 않았다

1995년경에는 혼란이 충분히 명시적이어서 RFC 1796이Not All RFCs are Standards라는 제목을 달게 되었습니다. 이 문서는 RFC 체계를 인터넷 표준과 기타 간행물의 출판 채널로 기술했습니다. RFC로 발표되는 것 자체는 표준으로서의 인정을 부여하지 않는다고 말했습니다.

실패는 흔히 인용 과정에서 일어났습니다. 각 RFC는 표준 절차와의 관계에서 상태를 가졌지만, 참조는 때때로 번호만 남기고 상태를 생략했습니다. 포인터는 기술적으로 정확하게 남으면서 그 권위는 재전달 속에서 커졌습니다. 무해해 보이는 압축이 사실상 주장의 변경이었습니다.

RFC 1796은 두 개의 번호 체계를 분리했습니다. RFC 번호는 문서를 식별했습니다. STD 번호는 표준 프로토콜을 식별했고, 그 관계는 일대일이 아니었습니다. 하나의 표준이 여러 RFC로 명시될 수 있는 반면, 문서는 추가 STD 정체성을 받더라도 자신의 RFC 번호를 유지했습니다. "어떤 RFC?"를 묻는 것과 "어떤 표준?"을 묻는 것은 관련된 질문이지 동의어가 아니었습니다.

이것은 얇은 레지스트리의 이례적으로 깨끗한 예입니다. RFC 번호는 고유성과 검색을 조율합니다. 상태, 개정, 채택, 구현에 관한 이후의 모든 사실을 인코딩하도록 요구되어서는 안 됩니다. 그런 사실들은 출처와 날짜가 보이는 연결된 기록에 속합니다.

하나의 아카이브는 더 약한 주장을 인정했기에 더 강했다

RFC 1796은 표준 간행물과 비표준 간행물을 별도 체계로 나누어야 한다는 반론을 검토했습니다. 그 대답은 구분이 중요하지 않은 것처럼 가장하는 것이 아니었습니다. 하나의 아카이브를 유지하면서 상태 가시성을 개선하는 것이었습니다.

단일 체계는 문서를 찾기 쉽게 하고 파일 서버 정리를 쉽게 했습니다. 저자들은 범위가 제한된 하위 체계는 사라지기 쉽다고 관찰했습니다. 그들은 또한 공개적으로 검색 가능한 실험적, 사적 개발 또는 실패한 사양이 사적 저장소에 숨겨진 것보다 낫다고 보았습니다. 배포된 제품은 그 사양을 찾을 수 있을 때 이해하기 쉬웠습니다. 그 사양이 인터넷 표준이 된 적이 없더라도.

따라서 폭넓은 보존과 엄격한 인정은 양립할 수 있습니다. 아카이브는 결론에 축복하지 않고 논의를 수용할 수 있습니다. 실패를 삭제하지 않고 실패한 제안을 보존할 수 있습니다. 운영자들이 떠난 뒤에도 역사적 사양을 이용 가능하게 유지할 수 있습니다. 그 가치는 가시성을 승리에 의존하지 않겠다는 결단에서 나옵니다.

대가는 메타데이터 규율입니다. 검색 결과, 인용, 조달 규칙이 상태, 날짜, 대체 관계를 떼어내면, 단일 아카이브는 단일 권위 층처럼 보이게 됩니다. 그것은 아카이브의 결함이 아니라 해석의 결함입니다.

표준 권위는 다른 증거 사슬에서 나왔다

RFC 2026은 이후 표준 절차를 훨씬 상세히 기술했습니다. 그 역시 RFC 체계를 표준 문서와 기타 자료의 출판 채널로 다뤘습니다. Experimental, Informational, Historic을 비표준 트랙 범주로 분류했고, Informational 사양은 커뮤니티 합의나 권고를 대표하지 않는다고 밝혔습니다.

인터넷 표준에 요구되는 증거는 달랐습니다: 기술적 역량, 공개 검토, 반복 개정, 다수의 독립적 상호운용 가능 구현, 운영 경험, 유용성, 지지, 관련 절차를 통한 정식 채택. 발표는 그 사슬의 한 부분이지 대체물이 아니었습니다.

RFC 8729는 이 건축적 아이디어를 이후의 제도적 형태로 보존했습니다. 하나의 RFC 체계가 서로 다른 승인 절차를 가진 서로 다른 스트림을 통해 문서를 받을 수 있었습니다. 그 체제에서는 IETF 스트림만이 Standards-Track 및 Best Current Practice RFC를 승인할 수 있었습니다. 공통 출판사와 아카이브는 승인의 출처를 지우지 않았습니다.

이 분리는 RFC 체계 밖에서도 유용합니다. 기록은 무언가가 작성되었음을 증명할 수 있습니다. 절차 기록은 누가 검토하거나 승인했는지 증명할 수 있습니다. 테스트는 명시된 조건 아래에서의 동작을 증명할 수 있습니다. 배포 증거는 실제로 누군가 사용했음을 증명할 수 있습니다. 어느 것도 다른 것을 사칭해서는 안 됩니다.

인용에는 상태를 담은 사슬이 필요하다

방어 가능한 참조는 최소한 RFC 번호, 제목, 날짜, 주장과 관련된 상태나 범주, 인용된 절, 알려진 대체 문서를 보존해야 합니다. 주장이 표준에 관한 것이면 표준 체계나 절차 증거도 식별해야 합니다. 동작에 관한 것이면 발표 너머의 구현 또는 운영 증거가 필요합니다.

동일한 규율이 부정적 결론에도 적용되어야 합니다. Informational은 기술적으로 열등하다는 뜻이 아닙니다. Experimental은 미사용이 아닙니다. Historic은 문서를 지우지도, 모든 메커니즘이 사라졌음을 증명하지도 않습니다. Standards Track은 제품을 인증하지 않습니다. 각 레이블은 주장을 좁힐 뿐, 이후의 모든 조사를 완성하지 않습니다.

RFC 825의 지속적 성취는 페이지 폭이 아니었습니다. 공통 아카이브가 차이를 노출해야 하며, 우연히 차이를 서열로 바꾸지 말아야 한다는 결정이었습니다. 번호는 문서가 어디 사는지 보존했습니다. 의도는 독자에게 문서가 무엇을 하려는지 알려주었습니다. 그보다 강한 모든 것은 여전히 다른 곳에서 얻어야 했습니다.

출처