요약

  • 1994년 12월의 RFC 1740은 Macintosh 파일을 MIME 메일에 넣는 방식을 정했다. AppleSingle은 내용과 속성을 하나의 바이트 흐름으로 묶고, AppleDouble은 Mac 전용 정보와 데이터 포크를 나눴다.
  • 별도 포장이 필요한 파일 대부분에는 multipart/appledouble이 선호됐다. application/applefile 부분에 리소스와 데스크톱 정보를 싣고, 데이터 부분에는 실제 내용에 맞는 MIME 형식을 붙였다.

파일이라는 말이 기계마다 달랐다

어떤 컴퓨터에서 파일은 길게 이어진 바이트 덩어리다. 전통적인 Macintosh 파일에는 데이터 포크와 리소스 포크가 있었다. 데이터 포크는 다른 컴퓨터에서도 대개 활용할 수 있는 내용을 담는다. 리소스 포크에는 프로그램 조각이나 아이콘 그림 같은 속성이 들어갈 수 있고, Finder가 관리하는 정보도 따로 따라온다. 메일은 서로 다른 파일 시스템을 지나는 운송 수단이었으므로, 이런 파일의 각 부분을 어디에 실을지 정해야 했다.

Patrik Faltstrom, Dave Crocker, Erik E. Fair은 RFC 1521의 MIME 구조를 이용했다. MIME 메일은 여러 본문 부분을 실을 수 있고, 부분마다 내용 형식을 표시한다. 덕분에 Mac의 특수 정보와 보편적인 데이터를 같은 편지에 담으면서도, 다른 기계의 독자가 데이터만 바로 읽을 길을 만들 수 있었다. 누가 어떤 칸을 열 것인가가 설계의 질문이었다.

AppleSingle은 하나의 단단한 상자였다. 파일 내용과 속성을 한 줄의 바이트 흐름으로 만들고 application/applefile이라는 꼬리표를 붙인다. Mac 파일을 통째로 보관하기에 알맞다. 하지만 사진 한 장이 필요한 비 Mac 독자는 먼저 AppleSingle 상자를 풀 도구를 찾아야 했다. 겉의 형식은 포장 방법을 알려 주고, 사진이라는 내용 형식은 상자 안에 숨어 있었다.

AppleDouble은 상자에 두 칸을 냈다. 헤더에는 리소스 포크와 데스크톱 정보가 들어가고, 데이터 포크는 별도로 간다. 바깥 형식 multipart/appledouble 아래에는 정확히 두 부분이 있다. 헤더는 application/applefile, 데이터는 내용에 알맞은 MIME 형식이다. RFC 예시는 image/gif를 썼고, 맞는 등록 형식이 없을 때는 application/octet-stream을 썼다. 다른 컴퓨터는 데이터 칸을 직접 열고, Mac은 두 칸을 합쳐 파일의 정보를 되살릴 수 있다.

규칙은 파일의 실제 짐을 살폈다. 이미 잘 알려진 MIME 형식이 있고 리소스 포크가 없거나 사소하다면 보통 MIME 부분으로 보내면 된다. 데이터 포크가 아예 없다면 AppleSingle을 쓴다. 분리해 줄 데이터가 없기 때문이다. 리소스가 중요하거나 데이터의 일반 형식이 없는 나머지 경우에는 AppleDouble이 통상적인 선택이었다. 빈 가방까지 두 개 부치라는 지시가 아니었다.

운송 중에는 옛 메일의 제약도 만났다. 바이너리인 AppleSingle 흐름과 AppleDouble 헤더는 제한적인 메일 경로를 통과하려면 전송 인코딩이 필요할 수 있었다. RFC는 Base64를 가장 안전한 방식으로 꼽았다. 받는 사람에게 파일 이름을 알려 주는 name 매개변수도 권했지만, MIME에서 물려받은 문법은 이 값을 7비트 US-ASCII로 제한했다. 파일의 구조는 꼼꼼히 챙겼는데 짐표를 적을 칸은 여전히 좁았다.

AppleDouble은 Mac의 개성을 지우는 방식으로 호환성을 만들지 않았다. 리소스와 Finder 정보는 Mac이 복원할 수 있게 남겼고, 데이터는 일반 MIME 도구가 알아볼 형식으로 꺼내 놓았다. 같은 메일을 받아도 독자는 필요한 쪽부터 연다. 포장의 구조가 각자에게 필요한 노동을 나눠 주었다.

RFC 1740의 무대는 MIME 종류와 바이너리 헤더다. 읽는 사람에게는 더 쉬운 이야기다. 동료가 Mac에서 보낸 사진을 다른 컴퓨터에서 열 수 있고, 그 파일이 Mac으로 돌아오면 원래의 부속 정보도 함께 온다. 봉투 하나에 칸 두 개를 낸 덕분이다.