요약

  • RFC 880는 공식 프로토콜 항목을 여러 개의 개별 주장 묶음으로 다루었습니다. 요구 수준, 정의 문서, 알려진 결함, 기타 참고 자료, 의존성, 연락처, 그리고 일부 경우 관찰된 사용이 함께 기록되었습니다.
  • 문서 자체의 항목들이 단일 라벨이 왜 불충분한지 보여줍니다. TCP는 문서화된 결함을 지니면서도 Recommended였고, TFTP는 이미 사용 중임에도 Elective였으며, GGP는 핵심 게이트웨이에서 운영 중인데도 Experimental로 분류되었습니다.
  • 이후 표준 프로세스 문서들은 성숙도와 요구 수준을 분리했고, 주기적 공식 요약본은 온라인 목록이 이를 대체하면서 결국 은퇴했습니다. 그러나 어떤 목록도 그 자체로 실제 동작을 증명할 수 없었습니다.

1983년 10월, 인터넷의 공식 프로토콜 스위트를 찾던 구현자는 깔끔한 제품 매트릭스를 받지 못했습니다.RFC 880, 즉Official Protocols는 그보다 훨씬 솔직한 내용을 제공했습니다. 이 문서는 사양을 명시하고, 상태를 부여하고, 의존성과 연락처를 나열한 뒤, 다소 불편한 사실들을 그대로 적었습니다.

어떤 사양은 오래되었습니다. 어떤 구현은 자신의 문서를 앞서 나갔습니다. 상태가 Experimental였음에도 사용 중인 프로토콜도 있었습니다. 문서는 있지만 일반적인 사용이 없는 옵션도 있었습니다. '공식'은 이 주석 달린 기록에 대한 소속을 의미했을 뿐, 그 기록을 보증서로 축소하지 않았습니다.

카탈로그는 시제가 흩어진 문서들에서 시작되었습니다

RFC 880는 1차적으로 공식 프로토콜이란 1982년 3월 Internet Protocol Transition Workbook에 실린 것들이라고 밝혔습니다. 그러나 곧바로 이 서술에 단서를 달았습니다. 사용 중인 여러 프로토콜이 워크북에 없었습니다. 워크북의 다른 프로토콜들은 개정되어 있었습니다. 메일은 더 새로운 권으로, Telnet과 가장 유용한 옵션들은 별도의 소책자로, 구현 지침은 별도 가이드로 옮겨갔고, 개정되지 않은 자료는 1978년 ARPANET Protocol Handbook에 그대로 남아 있었습니다.

따라서 이 목록은 단일하고 불변하는 진실의 원천을 발견한 것이 아니라, 움직이는 문서 자산을 조정한 것이었습니다. 그 전작인RFC 840은 6개월 전에 같은 기본 설계를 사용했고 이제는 폐기된 문서였습니다. RFC 840을 RFC 880로 대체하는 일은 부끄러운 일이 아니었습니다. 그것은 카탈로그 상태가 날짜를 지닌다는 증거였습니다.

모든 프로토콜 항목은 서로 다른 필드를 지녔습니다. STATUS는 요구 입장을 명시했습니다. SPECIFICATION은 정의 자료를 지목했습니다. COMMENTS는 이탈 사항, 결함, 계획된 작업을 기록했습니다. OTHER REFERENCES는 설명이나 갱신을 제공했습니다. DEPENDENCIES는 항목 아래 깔린 프로토콜들을 명시했고, CONTACT는 질문에 답할 수 있는 사람을 지목했습니다.

이 스키마는 흔한 범주 오류를 막았습니다. 문서는 충분하지 않으면서도 공식일 수 있었습니다. 프로토콜은 설치되지 않으면서도 권장될 수 있었습니다. 구현은 인용된 사양과 일치하지 않으면서도 작동할 수 있었습니다. 의존성은 상위 응용이 선택 사항일 때조차 필수일 수 있었습니다.

다섯 가지 상태는 권한을 서술했지, 하나의 위계 사다리가 아니었습니다

RFC 880는 Required, Recommended, Elective, Experimental, None을 정의했습니다. Required는 모든 호스트가 프로토콜을 구현해야 함을 뜻했습니다. Recommended는 모든 호스트가 구현하도록 권장됨을 의미했습니다. Elective는 구현 여부를 호스트에 맡겼습니다. Experimental은 실험에 참여하는 조율된 참가자들을 위한 것이었습니다. None은 항목 자체가 프로토콜이 아님을 뜻했습니다.

이 다섯 가지는 기술적 우수성의 등급이 아니었습니다. IP와 ICMP는 Required였습니다. UDP와 TCP는 Recommended였습니다. TFTP는 Elective였습니다. EGP와 GGP는 Experimental이었습니다. Catenet Model은 아키텍처를 서술할 뿐 유선 프로토콜이 아니기 때문에 None이었습니다.

상태는 기대되는 구현에 관한 한정된 질문에 답했습니다. 코드가 활성화되어 있는지, 상호 운용 가능한지, 안전한지, 완전한지, 지금 이 순간 작동하는지는 말하지 않았습니다. Required조차 선언을 소켓 응답으로 바꾸지 못했습니다.

TCP는 Recommended였고 여전히 오류 목록과 함께 도착했습니다

TCP 항목은 '공식'을 의례적으로 읽는 태도에 대한 가장 분명한 해독제입니다. RFC 880는 TCP를 Recommended로 분류하고 RFC 793을 가리켰습니다. 그리고 코멘트에서 많은 정정 사항이 접수되었으며 대부분은 프로토콜 결함이 아니라 문서 결함이라고 밝혔습니다.

항목은 일반적 경고에서 멈추지 않았습니다. 이벤트 처리 절에 명확화가 필요하다고 밝혔습니다. Push가 레코드 마크가 아니면서도 Push는 레코드 마크를 암시하는 언어를 여전히 지니고 있었습니다. 최대 세그먼트 크기의 기본값과 범위에도 작업이 필요했습니다. 유휴 연결은 유휴하다는 이유만으로 닫혀서는 안 되었습니다. 종료 시 큐에 남은 데이터와 순서가 어긋난 데이터의 보존에 대해 더 명확한 처리가 필요했습니다.

이 중 어느 것도 TCP를 비공식으로 만들지 않았습니다. 대신 카탈로그를 유용하게 만들었습니다. 상태는 구현 기대를 조정할 수 있었고, 코멘트는 미해결 해석을 보존했습니다. 'Recommended'만 복사한 조달 양식은 공식 항목이 중요하다고 본 바로 그 증거를 버리는 셈이었습니다.

Experimental은 네트워크에 없다는 뜻이 아니었습니다

라우팅 항목들은 분류와 실행을 더욱 선명하게 분리합니다. EGP는 Experimental로 개발 중이라고 서술되었습니다. GGP 역시 Experimental이었지만, 그 코멘트는 GGP가 당시 핵심 게이트웨이에서 사용되던 게이트웨이 프로토콜이라고 밝혔습니다.

이는 얼마나 많은 게이트웨이가 GGP를 운영했는지, 얼마나 잘 운영했는지, 그러한 배치가 얼마나 오래 지속되었는지에 대한 증명이 아닙니다. 하지만 잘못된 추론을 배반하기에는 충분합니다. 즉, Experimental은 운영상 사용이 전혀 없다는 뜻이 아니었습니다. 상태는 호스트가 프로토콜을 채택하거나 조율해야 하는 조건을 다스렸지, 유선 위의 패킷을 측정하지 않았습니다.

반대 방향의 불일치도 나타났습니다. Stream Protocol 항목은 그 구현이 진화하여 사양과 더 이상 일치하지 않을 수 있다고 말했습니다. 여기에는 실행 중인 코드가 존재했지만, 카탈로그는 존재가 적합성을 증명하도록 놔두지 않았습니다.

TFTP는 더 조용한 사례를 제공합니다. TFTP는 Elective였지만, 코멘트는 여러 로컬 네트워크에서 사용 중이라고 밝혔습니다. 선택 가능성과 채택은 서로 다른 필드에 놓여 있었습니다.

Telnet 옵션에는 자체적인 사용 열이 필요했습니다

RFC 880의 Telnet 옵션 표는 RFC 또는 NIC 문서, 새 Telnet 소책자 수재 여부, 구 핸드북 수재 여부, 그리고 USE를 위한 열을 지녔습니다. Binary Transmission, Echo, Suppress Go Ahead, Status, Timing Mark, Extended Options List는 자주 구현된 것으로 서술되었습니다. 다른 많은 옵션은 일반적 사용이 없었습니다.

옵션 계열 전체는 Elective였습니다. 그러나 카탈로그는 특정 옵션이 문서를 지니는지, 재출판되었는지, 구 자료에만 남아 있는지, 일반적으로 사용되는지를 여전히 구분했습니다. 형식적인 선택 가능성이 기능 수준의 보편성에 답하지 않았습니다.

이것이 중요한 이유는 프로토콜 이름이 넓은 선택적 표면을 가릴 수 있기 때문입니다. 'Telnet을 지원한다'는 말이 모든 옵션에 대한 지원을 증명하지 않았습니다. 문서 참조가 상대가 그 옵션을 협상할 것임을 증명하지도 않았습니다. USE 열은 불완전한 역사적 관찰이었지만, 실행 중인 코드가 별도의 주장을 필요로 한다는 점을 인정했습니다.

의존성과 연락처는 항목을 책임과 연결해 두었습니다

프로토콜은 목록에 홀로 등재된다고 해서 홀로 작동하지 않았습니다. SMTP는 TCP에 의존했습니다. TFTP는 UDP에 의존했습니다. Telnet은 TCP에 의존했습니다. 실험적 라우팅 프로토콜들은 IP에 의존했습니다. 의존성 필드는 상위 상태가 의미를 지니기 전에 어떤 하위 계약이 존재해야 하는지 보여주었습니다.

연락처 필드도 똑같이 실용적이었습니다. 실험적 사용은 연락 담당자와 조율되어야 했습니다. 명확화가 필요한 코멘트는 연락할 곳이 있었습니다. 이것이 한 사람에게 모든 구현에 대한 주권적 권한을 부여한 것은 아닙니다. 카탈로그가 분류를 통해 유지보수, 해석, 현지 판단이 사라진다고 가장하지 않도록 만들었습니다.

이후 판본들은 이 방법을 이어갔습니다.RFC 991은 자신을 공식 상태 보고서라고 칭하고 사양, 코멘트, 의존성, 연락처를 유지했습니다. 보고서의 연속성은 개정을 메커니즘의 일부로 만들었습니다.

성숙도와 요구는 결국 각각의 이름을 받았습니다

1991년까지,RFC 1200은 프로토콜의 표준화 STATE와 요구로서의 STATUS를 명시적으로 분리했습니다. Standard, Draft Standard, Proposed Standard, Experimental, Informational, Historic은 한 축을 서술했습니다. Required, Recommended, Elective, Limited Use, Not Recommended는 다른 축을 서술하였습니다.

RFC 2026은 표준 프로세스를 더 발전시켰습니다. 사양은 성숙도 수준을 통과할 수 있고, 적용 가능성 선언과 요구 수준은 어디에 사용되어야 하는지를 다루었습니다. 이후RFC 6410은 표준 트랙을 세 단계에서 두 단계로 축소했습니다. 프로세스를 바꾸는 것이 성숙도를 배포 카운터로 만들지는 않았습니다.

주기적 요약본 자체도 결국 신선함 시험을 통과하지 못했습니다.RFC 7100은 문서가 RFC 편집자의 온라인 목록에 밀려 사용되지 않게 되자, 마지막 Internet Official Protocol Standards 요약본과 STD 1을 은퇴시켰습니다. 데이터베이스가 주기적으로 교체되는 모놀리스보다 관리가 쉬웠습니다. 그러나 그 데이터베이스 역시 문서적 상태를 보고했지, 모든 구현의 상태를 보고하지는 않았습니다.

출처와 한계

이 글은RFC 840,RFC 880,RFC 991,RFC 1200,RFC 2026,RFC 6410,RFC 7100을 사용합니다. 이 문서들은 카탈로그와 프로세스의 역사를 확립합니다. 이것들은 현재 배포 점유율, 특정 제품의 적합성, 현재 보안 상태, 장애 사례, 또는 운영자의 정책을 확립하지 않습니다.