요약

  • RFC 1314는 팩스와 유사한 흑백 이미지를 위한 TIFF-B 교환 프로파일을 규정했다. 다중 페이지 파일, 페이지당 하나의 TIFF 스트립, 가능한 경우 MMR, 그리고 압축과 해상도에 대한 대안들이 정의되었다.
  • 이 RFC는 이미지 파일 형식과 파일이 전달되는 방식을 명시적으로 분리했다. FTP나 SMTP가 파일을 운반할 수 있었지만, 어느 프로토콜도 파일 자체의 속성은 아니었다.
  • 또한 호스트의 로컬 저장, 스캔, 파일 조작, 인쇄, 표시, 팩스 출력을 분리했다. 따라서 교환 파일에 대한 적합성은 전송, 렌더링된 페이지, 종이 사본, 성공한 팩스, 또는 읽는 이의 결과를 증명하지 않는다.

기다릴 수 있는 페이지

‘팩스’라는 말은 한때 하나의 일상적 동사 안에 전체 연쇄를 압축했다. 종이 한 장을 스캔하고, 부호화하고, 전화 회선을 통해 협상하고, 수신 측에서 복호화해 다른 종이 한 장에 담았다. 그 연쇄가 지나치게 단단하게 결합되어 있었기 때문에, 어느 지점에서의 실패는 곧 불편으로 이어졌다. 문서는 단계 사이에서 기다릴 수 있는 대상이 되지 못했고, 살아 있는 연결 자체가 ‘전송’의 의미 일부였다.

RFC 1314는 다른 환경을 바라보았다. 서문은 이미지가 스캐너, 소프트웨어 또는 팩스 기기에서 만들어진 뒤 조작되고, 전달되고, 공유되고, 복제되고, 표시되고, 인쇄되거나 팩스로 보내질 수 있다고 기술했다. 이 목록이 중요한 이유는 동의어의 나열이 아니기 때문이다. 각 동사는 서로 다른 조작, 서로 다른 시스템 경계, 그리고 잠재적으로 서로 다른 증거 기록을 가리킨다.

이 RFC가 제안한 모델은 거의 의도적으로 소박하다. 먼저 이미지를 파일로 스캔하거나 소프트웨어에서 만든다. 다음으로 저장하거나, 조작하거나, 전달한다. 인쇄나 표시는 그 뒤에 온다. 팩스 기기는 네트워크 그 자체가 아니라 종이와 파일 사이의 입출력 장치로 다뤄질 수 있었다. 이 모델은 문서가 특정 두 기기 사이의 끊기지 않는 대화에 덜 의존하게 만들었다.

동시에 ‘보냈다’라는 말을 덜 완전하게 만들었다. 저장된 파일은 전송된 파일이 아니다. 전송된 파일이 반드시 복호화된 파일인 것도 아니다. 복호화된 이미지가 반드시 표시된 페이지인 것도 아니고, 표시된 페이지가 종이 사본인 것도 아니다. 그 어느 기록도 읽는 이를 특정하지 않는다. RFC 1314는 이 모든 질문을 풀 필요가 없었다. 이 표준의 성과는 그 질문들을 성공처럼 보이는 하나의 사건 아래 묻어버리지 않고, 그대로 드러나 있게 둔 것이다.

TIFF-B가 표준화한 것

이 표준은 이미지 언어를 처음부터 새로 만들려 하지 않았다. TIFF를 틀로 선택해 인터넷 교환 프로파일로 제약한 것이다. 대표 프로파일은 TIFF-B였고, 다중 페이지 파일 지원과 페이지당 하나의 스트립을 갖추었다. 압축은 가능한 경우 MM(Modified Modified READ, MMR)이 선호되었다. Modified Huffman, Modified READ, 무압축도 허용되었으며, MH나 MR을 사용할 때는 스캔선이 바이트 정렬되어야 했다. 문서는 최대 상호운용성을 위해 제한된 해상도 집합을 권고했다. 600, 400 또는 300dpi, 또는 명시된 Group 3 팩스 계열이다.

이러한 제약은 구현체 사이의 계약으로서 중요하다. 수신자가 교환을 위해 받아들일 준비를 해야 하는 파일의 집합을 좁혀 준다. 그러나 이것은 결과에 대한 증명서가 아니다. TIFF-B 파일은 어느 전송 수단이 자신을 실어 날랐는지 밝히지 않는다. 원본 스캐너를 식별하지 않고, 발신자가 어떤 주소를 통제했다는 증명도, 수신자가 선택된 압축을 지원했다는 표시도, 모든 페이지가 변환을 무사히 통과했다는 보증도 하지 않는다. 페이지 수조차 대화, 프린터 트레이, 또는 사람의 주의가 아니라 파일에 관한 사실일 뿐이다.

RFC 1314는 이 점에서 신중했다. TIFF는 서로 다른 부호화 기법을 담을 수 있는 틀이며, 문서는 교환 프로파일을 정하면서도 모든 호스트가 로컬 이미지를 그 형태로 보관해야 한다고 선언하지 않았다. 호스트는 이미지를 자신만의 로컬 표현으로 저장하고 교환을 위해 변환할 수 있었다. 수신자가 파일의 압축을 처리하지 못한다면 변환이 필요할 수 있었다. RFC는 누가 그 변환을 수행해야 하는지, 어떤 알고리즘을 사용해야 하는지 말하기를 거부했다.

이 미해결의 책임은 덮어야 할 결함이 아니다. 그것은 경계다. 파일 형식 명세는 어떤 인터페이스에서 제공되는 형태를 정의할 수 있다. 그렇다고 해서 모든 변환에 대한 보관 책임을 배정하거나 변환이 충실했다는 것을 입증하지는 못한다. 그렇지 않다고 주장하는 순간, 표현 규칙이 관측되지 않은 운영 이력으로 둔갑한다.

전송 수단은 의도적으로 다른 곳에 있었다

RFC는 이미지 파일 형식이 파일의 전달 방식과 분리되어 있다고 분명히 밝힌다. FTP와 SMTP는 파일을 한 호스트에서 다른 호스트로 옮길 수 있는 방식의 예였다. 이 예들은 구분을 약하게 하지 않고 더 날카롭게 만든다. 하나의 시스템은 같은 교환 파일을 두 가지 이상의 메커니즘으로 운반할 수 있으며, 표현은 그대로인 채 전송 수단은 바뀔 수 있다.

당시 문서는 SMTP에 관한 실무적 복잡성, 파일 크기와 이진 자료 등도 언급했다. 그 관찰은 저자들이 논의한 제약에 관한 역사적 근거이며, 이후 모든 이메일 첨부에 대한 보편적 서사를 쓰는 허가가 아니다. FTP나 SMTP가 사용될 수 있다는 사실은 특정 파일에 실제로 어느 쪽이 사용되었다는 것을 입증하지도 않는다. 형식 헤더는 전송 로그, 수신 확인 또는 무결성 검사를 대신할 수 없다.

같은 분리는 저장에도 적용된다. RFC 1314는 교환 형식이 호스트의 이미지 저장에 그 형식을 요구하지 않는다고 명시한다. 적합한 호스트는 교환에 참여할 때 로컬 저장과 교환 파일 사이를 번역할 수 있다. 디스크 위의 파일은 마치 확정된 사실처럼 느껴지기 때문에 이 점은 놓치기 쉽다. 그러나 이미지의 로컬 표현, 공시된 교환 표현, 그리고 회선에 실려 나간 바이트는 서로 관련될 수 있으면서 동일하지 않을 수 있다.

그렇기 때문에 이 표준의 범위는 실용적인 증거적 교훈을 준다. 한 조직이 TIFF-B를 지원한다는 사실은 잠재적 인터페이스에 관한 말이다. 그것은 모든 원본 이미지를 보관했다는 것도, 하나의 전송 수단을 사용했다는 것도, 특정 목적지를 위해 변환을 완수했다는 것도 말해 주지 않는다. 호환성은 경계에서의 역량 주장이지, 그 경계를 넘을 수 있었던 모든 거래의 이력이 아니다.

팩스의 분해

RFC 1314의 기존 팩스와의 비교는 이 아키텍처를 읽을 수 있게 만든다. 전통적 팩스가 하나로 묶었던 네 가지 별개의 문제를 짚는다. 자료 표시와 압축, 자료 전송, 종이에서의 이미지 입력, 종이로의 이미지 출력. 이것들이 독립되면서 새로운 조합이 가능해진다. 소프트웨어가 만든 페이지는 이동 전에 저장될 수 있다. 스캔된 파일은 둘 이상의 목적지로 복제될 수 있다. 수신 시스템은 그것을 표시하거나, 인쇄하거나, 나중의 팩스 통화를 위해 준비할 수 있다.

표준은 그 어느 경로도 의무화하지 않는다. Group 4 이미지가 특정 장치에서 올바르게 인쇄될 것을 약속하지 않고, 일반 팩스 기기가 선택된 압축을 받아들일 것도 약속하지 않는다. 팩스 보드나 모뎀이 수신 팩스 기기와 협상할 수 있다는 점, 그리고 수신기가 파일의 압축을 처리하지 못할 때 변환이 필요할 수 있다는 점을 언급한다. 협상과 변환은 각자의 조건을 지닌 이후의 사건이다. 그것들을 파일이 그에 대한 증거를 지닌 것처럼 소급해 TIFF-B 파일 안에 넣어서는 안 된다.

이것은 어휘에 대한 경고 이상이다. 묶인 시스템은 기관이 하나의 상태 필드만 유지하도록 유혹한다. 전송됨, 완료됨, 성공함. RFC의 모델은 더 정직한 연쇄를 제안한다. 파일 생성, 교환을 위한 파일 선택, 특정 전송 수단에 파일을 둠, 바이트 수락 또는 거부, 파일 복호화, 파일 렌더링, 출력 장치 작동, 사람 또는 후속 프로세스의 응답. 그중 일부 기록은 존재하지 않을 수 있다. 존재하지 않을 때 바람직한 결론은, 남아 있는 가장 가까운 파일 기록을 나머지 전체로 승격시키는 것이 아니다.

공용 컨테이너, 보편적 증인은 아니다

인터넷 초기의 문서 시스템은 완벽한 보편 매체를 기다리기보다 기존의 기기와 소프트웨어 사이에서 협상해야 했다. RFC 1314는 제한된 공용 컨테이너와 좁은 상호운용 프로파일을 선택했다. 동시에 이 대상 이미지군이 나중에 더 포괄적인 ODA(Office Document Architecture) 표준으로 흡수될 수 있음을 예상하면서도, 당시의 설치 기반과 표준 성숙도는 그 미래 형태를 당장의 필요에 맞게 준비되었다고 보기 어렵다고 관찰했다.

이것은 현재 시점에서 판단할 예측이 아니다. 교환 표준은 영속성을 주장하지 않으면서 과도기적 목적을 가질 수 있음을 일깨워 준다. 각 시스템이 서로 다른 로컬 형식을 유지하고 이후 표준들이 등장하더라도, 프로파일은 하나의 경계에서 공유 최소치를 주기 때문에 유용할 수 있다. 공용 파일이 그 차이들을 해소하지는 않는다. 대신 인계를 더 명시적으로 만든다.

이 구분은 오늘에도 여전히 유효하다. 파일 이름, MIME 타입, 해시, 저장 위치가 마치 전체 워크플로를 서술하는 것처럼 다뤄지는 경우가 많다. 그러나 그렇지 않다. 해시는 바이트를 식별할 수 있어도 수신자의 경험을 식별하지 못한다. 전송 기록은 전송 사건을 보여 줄 수 있어도 표시된 이미지를 보여 주지 못한다. 프린터 스풀 항목은 장치 제출을 보여 줄 수 있어도 읽을 수 있는 종이를 보여 주지 못한다. RFC 1314는 현대의 디지털 증거 표준은 아니지만, 그 조작의 분리는 이러한 기록들의 혼동에 대한 내구성 있는 해독제다.

교환 파일이 정직하게 말할 수 있는 것

RFC 1314에 적합한 교환 파일은 구체적이고 제한된 진술을 지지할 수 있다. 정의된 프로파일에 따라 만들어졌다는 것, 특정 부호화와 페이지 배열을 갖는다는 것, 명시된 교환 경계에서 제공하기에 적합하다는 것. 추가적이고 독립적인 기록이 있으면 운영자는 더 확립할 수 있다. 특정 전송 서비스가 바이트를 수락했다는 것, 변환 프로그램이 실행되었다는 것, 장치가 작업을 보고했다는 것, 수신 시스템이 응답을 내보냈다는 것.

추가 진술 하나하나는 그에 속하는 기록을 필요로 한다. TIFF-B 프로파일의 어떤 것도 발신자를 인증된 인물로, 수신자를 확인된 목적지로, 표시된 창을 주의로, 출력 보고서를 인간의 결과로 만들지 않는다. 주장하지 않음 자체가 이 표준의 규율의 일부다.

RFC 1314의 조용한 역사적 기여는 이동이 이야기의 전부인 것처럼 꾸미지 않으면서 페이지를 이동 가능하게 만든 것이다. 이미지 파일은 단계 사이를 오갈 수 있는 내구성 있는 대상이 되었다. 그 대가로, 모든 단계는 스스로에 대해 답해야 했다.

출처와 근거의 한계

이 글은RFC 1314,인터넷에서 이미지를 교환하기 위한 파일 형식(1992년 4월)에 의존한다. 이 RFC는 TIFF-B 프로파일, 압축 및 해상도 지침, 교환 형식과 통신·저장의 분리, 팩스의 네 부분 구분, 스캔/저장·조작·전달/인쇄·표시 모델을 뒷받침한다. 개별 전송, 발신자, 수신자, 표시, 인쇄, 팩스, 변환, 수신자의 행위, 현재의 배포 또는 상업적 결과에 대해서는 어떤 근거도 제공하지 않는다.