목소리는 메일로 왔다. 컴퓨터에는 들려줄 입이 없었다.

요약

• Jon Postel의 RFC 807은 1982년 1월 멀티미디어 메일 회의를 기록했다. 받는 기계에 LPC 보코더처럼 자료를 보여 주거나 들려줄 장치가 없다면, 그 자료가 존재하고 어떤 종류인지 사용자에게 알리자는 것이 참석자들의 대체적인 의견이었다.
• 흑백 비트맵 교환에는 CCITT T.4 부호화를 쓰기로 합의했다. 첫 실험은 RFC 759 문서 전체를 파일로 보내고, 글은 RFC 767 문단 형식을 따르기로 했다. 부분 포인터와 중계 경로를 거치는 선택적 요청은 계속 연구할 문제였다.

메일 한 통에 글, 그림, 음성이 들어 있다. 글은 읽히고 그림은 뜬다. 음성 데이터도 도착했지만 받는 컴퓨터에는 소리로 바꿀 장치가 없다. 화면은 무엇을 말해야 할까? 1982년 1월 12일 Information Sciences Institute에 모인 연구자들은 이렇게 답했다. 보여 주지 못하는 데이터가 있음을 알리고 종류를 밝혀라. Jon Postel이 다음 달 발표한 RFC 807에 적힌 논의다. 앞의 메일은 상황을 보여 주는 예이고, 장비가 없는 수신자의 문제는 원문에 나온다.

참가 연구실의 장비는 가지각색이었다. CMU는 PERQ, 팩스와 LPC 보코더를 다뤘고, ISI는 TOPS20과 PERQ, Rapicom 450을 썼다. MIT의 Apollo는 네트워크 연결 장치를 기다리고 있었다. COMSAT는 팩스 부호화, BBN은 배포와 사생활 문제, UCL은 비트맵 처리, SRI는 보안과 글·그림 혼합 화면을 연구했다. 파일 형식을 맞춘다고 일곱 연구실에 같은 재생 장치가 생기지는 않는다.

회의록의 ‘장비 차이’ 항목은 수신자의 책상에서 이야기를 시작한다. LPC 보코더가 없으면 음성의 비트는 있어도 사람이 들을 소리를 만들지 못한다. 참석자들의 일반적인 생각은 숨기지 말고 사용자에게 자료의 존재와 종류를 말하자는 것이었다. 표준 형태를 몇 가지나 허용할지, 매체별 메모리·CPU·표시 시간을 어떻게 계산할지는 뒤로 남았다. 적어도 전송 완료와 사람에게 표현 완료는 다른 사건이었다.

흑백 그림에는 공통 선택이 있었다. 교환할 비트맵은 CCITT T.4 방식으로 부호화한다. 계획한 실험에서는 수정한 COMSAT 이미지 구조에 원시 비트맵 또는 CCITT 부호화 결과를 담는다. 이 선택은 다른 장소가 그림의 비트를 같은 방식으로 해석하게 도울 수 있다. 소리를 재생할 하드웨어의 부재까지 해결하는 형식은 아니었다.

더 영리해 보이는 방안도 나왔다. 송신자가 문서 각 부분의 포인터만 먼저 보내고, 수신자가 다룰 수 있는 부분을 요청한다. 하지만 메일이 중계기를 거치면 그 요청은 어디로 향할까? 글과 그림과 음성이 촘촘히 섞였다면 부분의 경계는 어떻게 나눌까? 첨부와 상호 참조까지 한 번에 정하기 어려웠다. 그래서 첫 실험은 문서 전체를 보내기로 했다. 복잡한 선택 메뉴보다 서로 다른 연구실 사이에 한 통을 실제로 건네는 일이 먼저였다.

시험 재료는 구체적이었다. 이용 가능한 파일 전송 방식으로 완전한 RFC 759 문서를 옮긴다. 글은 RFC 767 문단 형식을 사용하고, 그림은 수정 COMSAT 구조에 원시 또는 CCITT 부호화로 넣는다. 모든 장소에는 팩스와 글을 묶은 문서 교환 시연이 1982년 4월 19~20일 기한으로 배정됐다. 2월에 나온 회의록은 과제와 기한을 적었고, 시연 결과는 담지 않았다. National Bureau of Standards의 메일 형식과 RFC 759+767을 비교하는 일도 숙제였다.

멀티미디어 편집법은 각 팀이 먼저 만들고 나중에 비교하기로 했다. 그림의 회전·확대·잘라붙이기, 사서함 식별, 저장과 전송 비용, 기존 글 전용 메일과의 연결도 후속 과제였다. 연구실마다 다른 기계가 문제의 일부였으므로, 차이를 무시한 만능 양식을 선언할 수 없었다.

회의에서 가장 사용자 친화적인 문장은 아주 짧다. 자료가 왔고, 종류는 알며, 이 기계에서는 표현할 수 없다고 말하라. 1982년의 음성 메일은 재생 장치를 만나기 전에 목적지에 도착할 수 있었다. 그럴 때 침묵보다 정확한 한 줄이 낫다.