요약

  • RFC 1957이 언급한 두 클라이언트는 상태 표시자 뒤에 공백이 없으면 실패했지만, RFC 1939는 축약 응답을 허용했습니다.
  • Netscape는 UIDL을, Eudora는 TOP을 요구했으며, 이 두 명령은 RFC 1939가 선택 사항으로 분류한 것들이었습니다.
  • 널리 쓰이는 구현은 이렇게 표준을 공식적으로 수정하지 않고도 사실상의 호환성을 강제할 수 있습니다.

이후 Qualcomm이 개발한 UCBpopper서버는 상태 표시자에 항상 부가 정보를 덧붙였습니다. 그래서+OK나-ERR뒤에는 항상 공백이 따라왔습니다. 이 선택은 서버에 아무 문제가 없었고, 응답을 읽는 사람에게는 오히려 유용해 보일 수도 있었습니다.

취약성은 반대쪽에 있었습니다. RFC 1957은 자유롭게 복제 가능한 Unix 클라이언트popclient와 상용 제품netApp Systems Internet Series가 이 공백을 기대했고, 공백이 없으면 실패했다고 말합니다. 그러나 RFC 1939는 뒤에 이어지는 텍스트가 없을 때는 공백을 요구하지 않았습니다. 가장 짧은 구현은 프로토콜을 준수하면서도 상호 운용성을 잃을 수 있었습니다.

이 세부 사항은 경합하는 질서 구조를 드러냅니다. 문서는 여러 허용 가능한 응답을 정의합니다. 매우 널리 쓰이는 구현은 그중 하나만 내보냅니다. 클라이언트들은 주로 그 구현과의 테스트를 거치며 하나만 받아들이도록 배웁니다. 그러면 허용된 다양성은 투표 없이, 새로운 규범적 요구 없이, 심지어 명시적 결정 없이도 사라집니다.

RFC 1957의 대응은 실용적이지만 한계가 있습니다. 두 클라이언트의 저자들과 접촉했고, 새 버전은 더 이상 공백에 의존하지 않도록 할 예정이었습니다. 그러나 구버전 역시 지원해야 했습니다. 미래를 고치는 것이 설치된 기반을 즉시 지워주지는 않습니다. 운영자는 때때로 알려진 이상 동작을 재현하면서 그 소멸을 조직해야 합니다.

같은 현상이 기능 수준에서도 나타납니다. RFC 1939는 TOP과 UIDL을 선택 사항 명령으로 분류합니다. 그러나 RFC 1957은 Netscape가 UIDL을, Eudora가 TOP을 요구했다고 지적합니다. 여기서 이 명령들의 기능을 설명하려는 것이 아닙니다. 쟁점은 접근입니다. 서버의 옵션이, 인기 클라이언트의 기대를 통해, 사용자에게 서비스를 제공하기 위한 사실상의 조건이 되었습니다.

그 당시 기능 발견 능력은 미약했습니다. RFC 1939는 선택 사항 명령의 부재를 일시적 또는 문맥적 거부와 구별하는 일반적인 방법을 제시하지 않았습니다. 이후 RFC 2449는 옵션들을, 감지 가능하다면 시도를 통해서만 감지 가능한 것으로 기술하고, TOP과 UIDL 등을 알리는 CAPA를 도입할 것입니다. 이 변화는 계약을 더 잘 보이게 만들지만, RFC 1957이 그 원인이었다거나 모든 소프트웨어가 이를 채택했다고 증명하지는 않습니다.

증거의 범위는 정확하게 유지되어야 합니다. RFC 1957은 1996년 6월의 정보성 문서로, 한 달 전 표준화 경로에서 발행된 RFC 1939를 갱신합니다. 이 문서는 구체적인 소프트웨어를 인용할 뿐, 통계적 모집단을 다루지 않습니다. 시장 점유율도, 장애 지속 시간도, 비용도 측정하지 않습니다. 공백, TOP, UIDL을 규범적 의무로 바꾸지도 않습니다.

이 문서의 역사적 힘은 과장을 거부하는 데서 옵니다. 이 문서는 운영상의 의무가 줄 사이에서 어떻게 태어나는지 보여줍니다. 흔한 서버는 안정적인 잉여를 만들어내고, 흔한 클라이언트는 그것을 필요로 소비하며, 이후 새로 등장하는 모든 구현은 텍스트와 세계 중 하나를 선택해야 합니다. 작동하는 코드는 의존성이 어디 있는지를 말해주지만, 권한이 어디 있어야 하는지까지 말해주지는 못합니다.

출처