요약

  • RFC 1049는 PostScript, TeX, TROFF 같은 구조화된 메일 본문을 위한 Content-Type 필드를 제안했다. 본문은 당시 메일의 ASCII 제한 안에서 운반되고, 읽기 프로그램은 필드를 보고 표시 도구를 고를 수 있다.
  • 형식 이름에 버전과 필요한 자원 참조도 붙일 수 있었다. 수신자의 처리 능력을 자동으로 알아내는 체계가 없던 단계라 발신자가 대응 가능한 사람들의 목록을 직접 관리했다. 이후 RFC 2045가 이 필드를 MIME에 맞게 확장했다.

한 글자도 빠짐없이 전달된 문서가 읽기에는 실패할 수 있다. 1988년의 메일함에 PostScript 문서가 들어오면 평범한 메일 화면은 프린터에 줄 명령을 성실하게 늘어놓는다. 보낸 사람은 수식과 조판을 보여 주려 했는데 받는 사람은 무대 뒤 작업 지시서를 읽는다. Martin Sirbu가 1988년 3월 낸 RFC 1049는 메일이 본문의 정체를 먼저 알리도록 제안했다.

RFC 822 메일에는 정해진 헤더와 ASCII 문자로 된 본문이 있었다. 사용자들은 그 본문에 TROFF, TeX, Scribe, SGML, DVI, PostScript를 넣기 시작했다. 문자 규칙을 지키며 이동할 수는 있지만 의도한 페이지로 보려면 별도 프로그램이 필요하다. Content-Type 필드는 읽기 프로그램이 형식을 알아보고 본문을 알맞은 처리기로 넘길 길을 연다. 메일 경로는 문자를 운반하고, 화면에 어떻게 보일지는 수신 쪽에서 결정한다.

Sirbu의 이름표에는 꽤 많은 정보가 들어갔다. 먼저 POSTSCRIPT나 TROFF 같은 형식 이름이 오고, 사적으로 약속한 X- 형식도 허용된다. 필요하면 버전 번호, 해석에 쓰는 자원 참조, 주석이 이어진다. RFC는 PostScript용 LaserPrep 버전과 TROFF용 eqn, tbl, me를 예로 들었다. 음식 이름을 안다고 부엌에 필요한 도구까지 생기지는 않는다. 자원 참조는 그 숨은 의존성을 메일에 함께 적으려는 장치였다.

수신 쪽에 해석기가 없다면 ASCII 메일은 도착하고 화면에는 원시 명령이 나타난다. 발신자는 누가 PostScript를 볼 수 있는지 어떻게 알까? RFC는 세 길을 검토했다. 발신 시스템마다 원격 장비의 능력을 기록하거나, SMTP가 전송 중 협상하고 변환하거나, 디렉터리가 수신 장비의 능력을 공개하는 방법이다. 첫째는 계속 갱신해야 하고, 둘째는 기존 메일 프로그램을 바꾸면서 다른 네트워크를 지나는 길도 고려해야 하며, 셋째는 발송과 이름 서비스에 새 일을 얹는다.

당장 실험을 시작하기 위해 Sirbu가 고른 답은 뜻밖에 손맛이 강했다. 발신자가 누구에게 어떤 형식을 보낼 수 있는지 사적인 목록을 갖고 있으라는 것이다. 메일 본문에는 표준 이름표가 생겼지만, 친구들의 장비 목록은 사람의 수첩에 남았다. RFC는 올바른 필드를 본 읽기 프로그램의 구체적인 반응도 각자 결정하도록 두었다. 형식을 알아보는 일, 해석기를 갖추는 일, 결과를 보기 좋게 보여 주는 일은 서로 다른 작업이다.

나중의 RFC 2045는 MIME의 Content-Type이 RFC 1049의 필드를 일반화했다고 명시했다. MIME에는 미디어 유형과 하위 유형, 매개변수, 그리고 MIME-Version과 Content-Transfer-Encoding 같은 동반 필드가 생겼다. 1996년 문서는 1988년 구문을 더 단순하며 대체로 호환된다고 설명했다. 초기 제안의 묘미는 따로 있다. 메일은 무엇이 들어 있는지 말하기 시작했지만, 상대가 그것을 읽을 수 있는지는 보낸 사람이 챙겼다.

작은 이름표 덕분에 수신자는 명령으로 가득한 화면을 보며 형식을 추리할 필요가 줄었다. 다음 질문은 더 비쌌다. 누가 해석기와 맞는 버전, 보조 자원을 갖고 있는가? 한동안 가장 중요한 능력 데이터베이스는 ‘보내기’를 누르는 사람의 머릿속에 있었다.