Summary

  • RFC 769은 Rapicom 450 팩스 데이터를 파일로 저장하는 형식을 설명해, 호환 장비를 갖춘 ARPA Internet의 기관이 파일 전송 등으로 저장된 페이지를 교환할 수 있게 했다.
  • 파일은 준비 블록, 데이터 블록, 끝을 구분했다. 내부의 585비트 블록은 장비 고유의 부호를 유지했으므로 이미지로 되돌리려면 그 장비의 해독 절차가 필요했다.

종이 한 장이 팩스에 들어가 컴퓨터 파일로 나온다. 오늘은 사소해 보이지만, 1980년 9월에는 여러 기관이 실제 장비를 맞춰야 가능한 교환 방식이었다. ARPA Internet 공동체의 일부 기관에는 컴퓨터와 연결된 Rapicom 450이 있었다. Jon Postel의 RFC 769은 같은 계열의 기계를 가진 다른 기관도 이 방식에 참여하도록 파일 구조를 기록했다. 종이가 책상에서 떠나 데이터가 되는 순간이었다.

파일이 된다고 그림의 뜻까지 공개되는 것은 아니었다. Rapicom 450은 자체 인코딩 방식으로 585비트짜리 블록을 만들었다. 컴퓨터는 이를 저장하고, 네트워크는 다른 곳으로 보낼 수 있다. 하지만 블록을 비트맵으로 쓰려면 기계의 인코딩과 디코딩 절차를 알아야 한다고 RFC는 적었다. 택배 상자는 무사히 도착했다. 안에 든 편지는 그 기계의 글씨체로 쓰여 있었다.

Postel이 공동으로 정한 것은 상자의 바깥 모양이었다. 각 기록에는 길이를 나타내는 1바이트, 명령을 나타내는 1바이트, 이어서 데이터가 붙었다. 길이에는 앞의 두 바이트도 포함됐다. 명령 56은 SET-UP, 57은 DATA, 58은 END를 뜻했다. 마지막 END 기록은 앞의 두 바이트만 가질 수도 있었다. 파일을 받는 컴퓨터는 어디가 준비이고 본문이며 끝인지 정확히 알 수 있었다.

준비 블록에서는 파일과 장비의 동작이 갈라진다. Rapicom 450은 작업 중 똑같은 SET-UP 블록을 여러 번 보내거나 받았다. 저장 파일에는 그중 하나만 남겼다. 장비의 모든 반복 동작을 보존하기보다, 다른 호환 장비가 쓸 표현을 골라 담은 것이다. 작동 기록과 교환용 파일은 같은 물건이 아니었다.

숫자도 한 번에 맞아떨어지지 않았다. 73바이트는 584비트다. 장비 블록 585비트를 담기에는 딱 한 비트 부족하다. 그래서 데이터 영역을 74바이트로 만들고, 길이와 명령 바이트를 더해 일반 기록이 76바이트가 되었다. RFC가 당시 이미 교환됐다고 밝힌 파일은 기록 하나에 장비 블록 하나를 넣었다. 첫 기록은 SET-UP, 중간은 DATA, 끝은 END였다. 한 비트를 얕보면 그 뒤의 페이지가 줄줄이 엇나갈 수 있다.

문서는 블록 첫머리의 24비트 동기화 표식과, DATA에서 네 가지 값을 차례로 도는 2비트 순서 번호도 적었다. 이 표식들은 장비가 만든 블록을 알아보고 경계를 유지하는 데 쓰였다. 그림의 화소를 스스로 설명하지는 않았다. 전송 장치는 파일을 옮기고, 파일 판독기는 기록을 나누고, Rapicom의 해독 절차가 페이지를 다시 만든다. 한 번의 «보내기» 속에 서로 다른 세 작업이 들어 있었다.

1980년 문서가 초대한 사람은 호환 팩스를 가진 기관이었다. 12년 뒤 RFC 1314는 인터넷에서 팩스와 비슷한 이미지를 더 널리 교환하기 위한 독립적인 TIFF-B 파일 형식을 다뤘다. 두 문서를 나란히 놓으면 목표가 또렷해진다. 앞의 것은 특정 기계의 자료를 교환하는 규칙이고, 뒤의 것은 그림 자체의 표현을 더 폭넓게 맞추려는 시도다.

종이가 장비에 들어가고, 부호화된 블록이 파일에 담기고, 파일이 네트워크를 건너고, 반대편의 호환 장비가 다시 페이지를 만든다. RFC 769이 남긴 역사는 이 단계들을 한 동사로 뭉개지 않는 데 있다. 페이지를 데이터로 보낼 수 있게 된 것은 진짜 진전이었다. 받는 쪽 책상에도 그 데이터를 읽는 기계가 있어야 했다.