편지는 한 통, 길은 여러 개, 파일은 두 개

요약

• RFC 784는 TOPS20의 메일 분배기가 목적지 호스트의 능력표를 보고 TCP 위의 MTP, NCP 위의 MTP, 옛 FTP/NCP 또는 특별 경로를 고르는 구상을 적었다.
• RFC 785는 메일 본문과 배송 제어를 두 파일로 나눴다. 제어 파일에는 발신자, 수신자별 경로와 본문 파일 위치가 적히며, 수신자별 진행 상태에 따라 바뀔 수 있었다.

네 사람에게 같은 편지를 보내려면 본문 하나와 주소 네 개면 된다. 옛 메일 작성 프로그램 중에는 주소마다 본문 파일을 새로 만드는 것도 있었다. Suzanne Sluizer와 Jon Postel은 1981년 7월 다른 방법을 제안했다. ISI TOPS20에서 MTP를 구현하려는 계획을 담은 RFC 784는 편지와 배달 지시서를 별도 파일로 뒀다. 길이 막히면 지시서에 표시하면 된다. 편지를 다시 타이핑할 이유가 없다.

당시 길은 하나가 아니었다. 두 사람이 BLISS-10으로 만들고 있던 프로그램은 TCP와 앞선 NCP에서 MTP를 송수신하고 다른 메일 체계와도 연결될 예정이었다. 사용자의 작성 프로그램과 네트워크 수신 프로그램이 사용자 디렉터리에 파일을 만들면, 백그라운드 분배기가 출력 채널로 보낸다. 사용자가 직접 호출하는 판은 필요한 채널이 열려 있을 때 바로 보내려 했다. 호스트 능력표에는 목적지가 TCP 위의 MTP, NCP 위의 MTP, 기존 방식인 NCP 위의 FTP 중 무엇을 받을 수 있는지 기록했다. 별도 표에는 UCL의 시스템을 통해 영국 호스트로 보내는 식의 예외 경로가 있었다.

수신자마다 일의 속도가 달라질 수 있었다. 제어 파일은 배송 정보와 본문 파일을 가리키는 위치를 담았다. 본문 파일에는 RFC 733 형식의 머리말을 포함한 메일 내용이 있었다. 한 사람에게 보내는 단계가 끝나면 분배기는 제어 파일에서 그 사람을 표시하거나 뺄 수 있다. 다른 채널이 닫혀 있으면 그 수신자는 기다리는 목록에 남는다. 본문은 각 시도에서 읽고, 현지 처리가 끝나면 파일을 이름 바꾸거나 삭제할 수 있었다. 바뀌는 것은 분배기의 업무 상태다. 그래서 그 상태를 별도 종이에 적은 셈이다.

파일 형식을 정한 RFC 785는 그 종이의 칸을 정확히 보여 준다. FILE:에는 본문 파일의 전체 이름, FROM:에는 발신 경로, 여러 개의 TO:에는 각각의 목적지 경로가 들어간다. 다른 파일에 머리말과 본문이 놓인다. 저자들은 To, Cc, Bcc의 주소가 N개면 본문도 N개 만들던 옛 방식과 이를 비교했다. 새 인터페이스는 수신자가 몇 명이든 두 파일로 시작한다. 사람이 읽는 메일 머리말과 기계가 처리하는 배송 목록은 서로 다른 일을 한다.

다음 우체국의 주소 체계도 맞춰야 했다. RFC 786은 MTP와 NIMAIL 사이에서 파일을 주고받는 방법을 설명하며, 퍼센트 기호가 들어간 주소를 MTP 경로로 바꾸는 사례와 그 반대를 들었다. 어느 채널을 탈지 아는 데 이어, 다음 시스템이 읽을 수 있는 주소로 넘겨야 했다. 편지를 담은 봉투의 표기법도 경로의 일부였다.

Sluizer와 Postel은 만들고 있는 구성 요소, 다른 메일 프로그램이 고쳐 주기를 바라는 부분, 새로 채울 표를 구분해 적었다. RFC 784는 구체적인 구현 계획이고, RFC 785는 파일 사이의 접점을 자세히 정했다. 여기서 보이는 핵심은 수신자마다 남은 일을 따로 기록하는 방식이다. 같은 문장을 받을 사람이어도 한 명은 다음 길로 나아가고 다른 한 명은 기다릴 수 있었다.

책상 위에는 편지 한 통이 있다. 옆 카드에는 이름마다 나갈 문이 적혀 있다. 1981년의 문에는 TCP, NCP, NCP 위의 FTP라는 이름이 붙어 있었다. 닫힌 문 앞의 이름은 카드에 남겨 두고 다른 길의 작업은 계속한다. 두 파일은 컴퓨터 안에 작은 우편 분류대를 만든 것이다.