요약

  • RFC 1176은 FIND MAILBOXES와 FIND BBOARDS를 선택 명령으로 뒀다. BAD가 돌아와도 클라이언트는 실패 원인을 단정할 수 없었다.
  • RFC 1203은 이를 겨냥한 반대 제안이라고 밝히고, 서버의 지원 버전과 기능을 먼저 알아낸 뒤 선택하는 절차를 적었다.

메일 프로그램에 ‘사서함 찾기’ 버튼을 넣는 순간 문제가 생긴다. 연결된 서버가 그 명령을 아는가. 1990년 RFC 1176은 FIND MAILBOXES를 선택 기능으로 두면서, 요청에 BAD가 오면 클라이언트가 원인을 추론할 수 없다고 했다. FIND BBOARDS도 마찬가지였다. 서버는 자기 기능을 알고 있었지만, 프로그램이 버튼을 그리기 전에 확인할 길은 없었다.

John Rice는 1991년 2월 RFC 1203을 IMAP3의 이름으로 냈다. 서두부터 RFC 1176에 대한 반대 제안이라고 했다. 앞선 개정이 IMAP 공동체 내부 협의 없이 이루어졌다는 비판도 담았다. 그 절차 평가는 Rice의 주장이다. 두 문서에서 직접 확인되는 기술적 다툼은 더 선명하다. 하나는 선택 명령을 열어 두고 지원 목록을 물을 수 없게 했고, 다른 하나는 먼저 목록을 요구했다.

IMAP3가 제안한 순서는 이렇다. SUPPORTED.VERSIONS로 서버의 버전과 기능을 받고, SELECT.VERSION으로 버전을 정한다. SELECT.FEATURES로 개별 기능을 켜거나 끈다. 문서의 예시는 목록 조회 뒤 3.0을 선택하고 TAGGED.SOLICITED를 활성화한다. 없는 버전이나 기능을 요청하면 NO가 돌아온다. 프로그램은 사용자에게 시험 삼아 누르라고 하기 전에 실행 가능한 메뉴를 만들 수 있다.

기존 클라이언트를 위한 기본값도 남겼다. 서버는 별도 선택이 없으면 RFC 1064의 IMAP2 방식으로 응답한다. 버전 선택은 사서함 선택보다 앞서야 했다. 서버가 다른 버전을 처리하려고 다른 프로그램을 띄우면 기존 세션 상태를 이어받지 못할 수 있기 때문이다. 변경의 시점을 데이터가 쌓이기 전으로 당긴 셈이다.

클라이언트 내부 설계도 논쟁 대상이었다. RFC 1176의 부록은 사서함의 불완전한 모형인 로컬 캐시를 유지하도록 설명했다. RFC 1203은 서버가 그 캐시 구조를 당연하게 여기는 데 반대했다. 명령에 반드시 따라오는 응답에는 해당 명령의 태그를, 서버가 자발적으로 보내는 정보에는 *를 붙이자는 구분도 세웠다. 여러 검색이 동시에 진행되고 저장 장치가 늦게 응답하면, 어느 결과가 어느 요청에 속하는지 알아야 한다.

RFC Editor 기록은 이 제안을 현재 Historic으로 표시한다. 당시 인터넷 공동체에 대한 지위는 Experimental이었다. 이 기록은 어느 쪽이 몇 대의 서버를 차지했는지 말하지 않는다. 대신 한 가지 실무 질문을 남긴다. 기능을 아는 서버가 미리 알릴 것인가, 모르고 있는 클라이언트가 실패를 반복할 것인가. IMAP3는 비용을 숨기는 쪽을 거절했다.

출처