요약

  • RFC 1927은 전자 스테이플러와 종이클립을 제안해 다중 파트 문서가 얼마나 단단히 묶여 있는지를 보여 주려 했습니다. 그 농담은 같은 대상에 외양, 워크플로, 과금, 재활용, 위치 의미까지 얹었습니다.
  • 이후 MIME 규격은 이런 관심사를 분리했습니다. Content-Disposition은 표시 힌트를 제공했고,multipart/related는 복합 객체와 그 루트를 정의했으며,cid:나mid:는 범위가 지정된 참조를 제공했습니다.
  • 지속 가능한 관계에는 수신자가 검증할 수 있는 명시적 의미론이 필요합니다. 익숙한 아이콘은 관계를 설명할 수 있지만, 파일을 옮기거나 워크플로를 작동시키거나 무결성을 판단하는 권한을 가져서는 안 됩니다.

하나의 사무용 물건, 너무 많은 종류의 '함께함'

RFC 1927의 첫 명제는 놀랍도록 간결합니다. 전자 스테이플러와 종이클립은 다중 파트 문서의 "결합 정도"를 나타낼 것입니다. 스테이플된 문서는 데스크톱에서 함께 유지되고, 클립된 문서는 쉽게 펼쳐질 것입니다. 종이를 다뤄 본 사람이라면 문법 규칙을 찾아보지 않고도 이 구분을 이해합니다.

하지만 메모는 곧바로 이 단순성을 불안정하게 만듭니다. 큰 클립과 작은 클립은 문서 크기나 계층적 조립을 나타낼 수 있습니다. 모든 클립에 붙는 인증서는 과금을 지원하고 특허 위반을 탐지할 수 있습니다. 재활용 시스템은 폴더가 삭제될 때 체결물을 회수할 수 있습니다. 색과 모양은 아이콘을 바꿀 수 있고,src=속성은 이미지를 불러올 수 있으며, 은색이나 금색은 서로 다른 사무 워크플로를 선택할 수 있습니다. 클립은 페이지, 단락 또는 문장을 표시할 수도 있습니다. 심지어 자신이 몇 번 구부러졌는지 기억했다가 결국 고장날 수도 있습니다.

이것들은 하나의 관계를 이룬 변형이 아닙니다. 포함, 순서, 표시, 식별, 권한 부여, 과금, 수명 주기, 앵커링, 가변 상태에 대한 별개의 주장들입니다. 유머는 이 모든 것을 종이클립처럼 보이는 하나의 대상이 지닌 자연스러운 속성으로 취급하는 데서 나옵니다. 상호 운용성 문제는 같은 지점에서 시작됩니다. 다른 프로그램이 이 객체를 복사하거나, 전달하거나, 저장하거나, 열거나, 삭제할 때 정확히 무엇을 보존해야 하는가?

RFC 1927은 이 위험을 희극적 형식으로 인정합니다. 스테이플러와 클립은 고속 복사 프로그램을 망가뜨릴 수 있으며, 보안 섹션은 보안을 다루지 않는다고 명시합니다. 이 누락이 중요한 이유는, 제안된 외양 필드 하나가 워크플로까지 선택하기 때문입니다. 발신자가 색을 통제한다면, 발신자는 문서를 꾸민 것일까요, 아니면 명령을 내린 것일까요?

Informational은 경계였지, 부끄러움이 아니었다

문서 자체의 상태 고지는 이 문서가 정보를 제공하며 인터넷 표준을 지정하지 않는다고 말합니다.현재 RFC Editor 기록은 이 문서를 Independent Stream에 분류하고 오류 정정이 하나 등록되어 있음을 보여 줍니다. 발행일인 1996년 4월 1일과 아동 안전, 플로피 디스크, 조각상 관련 대목은 이 문서가 희극적 성격임을 의심할 여지 없이 드러냅니다.

그렇다고 이 문서가 분석적으로 텅 비어 있는 것은 아닙니다. 풍자는 정중한 버전에서 멈추기를 거부함으로써 설계상의 모호성을 찾아냅니다. "첨부"라는 말은 구현이 그것이 '이 파트들을 함께 표시하라', '함께 저장하라', '분리를 금지하라', '순서를 보존하라', '신원을 검증하라', '도착 시 동작을 실행하라' 중 무엇을 뜻하는지 판단해야 하기 전까지는 정확해 보입니다.

확인된 정정 기록은 "data flines"를 "data files"로 고치고 "very small children"을 "very young children"으로 바꿉니다. 편집자는 이 농담이 의도한 단어를 판별할 수 있습니다. 그러나 이 정정은 규격을 준수하는 전자 스테이플러가 무엇을 해야 하는지 정의하지 않습니다. 텍스트 유지보수와 운영 의미론은 여전히 별개의 작업입니다.

MIME은 콘텐츠 매개변수에 더 작은 역할을 부여했다

수정된 MIME 미디어 타입 규격은 1996년 말에 등장했습니다.RFC 2046은 Content-Type이 MIME 본문의 성격을 선언한다고 규정합니다. 매개변수는 서브타입을 수정하지만 콘텐츠의 본질을 근본적으로 바꾸지는 않으며, 구현은 인식하지 못하는 매개변수를 무시해야 합니다. 복합 형식은 매개변수에 다른 종류의 데이터를 몰래 넣는 대신 multipart 또는 application 타입을 사용해야 합니다.

이것은 RFC 1927의 상상 속color=,shape=,src=표면에 유용한 제약입니다. 표시 매개변수는 외양을 서술할 수 있습니다. 그러나 동시에 포함 관계를 재정의하고, 워크플로를 활성화하고, 내부 의존성의 유일한 기록이 되어서는 안 됩니다. 알 수 없는 매개변수는 확장성을 위해 통상적으로 무시됩니다. 정확성에 필수적인 관계가 모든 수신자가 장식적 필드를 명령으로 취급할 것을 요구할 수는 없습니다.

multipart/mixed역시 제한된 약속만 제공합니다. 이것은 독립적인 본문 파트들의 순서 있는 집합을 전송합니다. 파트들이 하나의 봉투로 경계를 넘어왔다는 사실은 그것들이 하나의 분리 불가능한 객체를 이룬다는 뜻이 아닙니다. 같은 위치에 있는 것은 포장의 증거일 뿐, 의존성의 증명이 아닙니다.

표시는 명령이 아니라 제안이 되었다

RFC 2183은 Content-Disposition을 통해 표시 계층을 명시적으로 명명했습니다.inline은 즉시 표시를 제안하고,attachment는 사용자가 추가 조치를 취하도록 제안합니다. 본문 파트가 별도로 저장될 경우 파일명을 제안할 수도 있습니다. 이것들은 유용한 지침이지만, 어휘는 의도적으로 절제되어 있습니다. 즉 disposition은 표시 정보를 전달할 뿐입니다.

그 보안 규칙은 이 절제가 왜 중요한지를 보여 줍니다. 수신 프로그램은 제안된 파일명을 맹목적으로 채택하거나, 디렉터리 경로를 수용하거나, 기존 파일을 덮어쓰거나, 실행 가능한 콘텐츠를 실행될 위치에 두어서는 안 됩니다. 발신자는 레이블을 제안할 수 있습니다. 그 제안이 수신자의 파일 시스템과 실행 환경에서 안전한지는 로컬 소프트웨어가 결정합니다.

이 경계가 금색 종이클립 문제의 진지한 버전입니다. 금색 아이콘은 사람이 로컬 큐를 인식하는 데 도움을 줄 수 있습니다. 그 의미가 한 사무실 안에서 명백하다는 이유만으로 휴대 가능한 권한 토큰이 될 수는 없습니다. 외양이 실행을 유발하는 순간, 수신자는 더 밝은 장식이 아니라 인증된 명령 어휘, 권한 판단, 실패 동작을 필요로 합니다.

복합 객체에는 루트와 명시적 관계가 필요했다

RFC 2387은 더 강한 사례를 위한multipart/related를 정의합니다. 구성 파트들이 서로 연관되어 있으며, 각 파트를 독립적으로 보여 주는 방식으로는 객체를 제대로 표시할 수 없습니다. type 매개변수는 루트 파트의 미디어 타입을 명명합니다. 선택적start매개변수는 Content-ID로 그 루트를 식별하며, 지정되지 않으면 첫 본문 파트가 루트입니다. 구성 요소 내부의 링크가 다른 구성 요소와의 관계를 표현합니다.

루트는 질문을 "어떤 조각들이 함께 도착했는가?"에서 "어떤 구성 요소가 객체를 정의하며, 어떤 자원을 필요로 하는가?"로 바꿉니다. 해석은 처리 응용 프로그램이 소유합니다. 인식된 related 객체 안에서 Content-Disposition은 중복되거나 오해를 일으킬 수 있으므로, related 객체 처리가 표시 힌트보다 우선합니다.

이것은 단지 더 풍부한 문법이 아닙니다. 눈에 보이는 배지가 구조적 진실의 유일한 근원이 되는 것을 막습니다. 복합 타입을 이해하는 수신자는 객체의 정의된 의미론에 따라 의존성을 해소할 수 있습니다. 이해하지 못하는 수신자는 알 수 없는 클립이 결합 연산을 수행했다고 가장하는 대신, 패키지를 mixed 파트로 취급하는 것으로 후퇴합니다.

참조에는 식별성과 맥락이 필요했다

두 아이콘을 가로지르는 스테이플러 그림조차 소프트웨어에게 어느 정확한 바이트가 어느 바이트에 의존하는지 알려 주지 못합니다.RFC 2392는 MIME 본문 파트를 가리키는cid:참조와, 메시지 또는 명명된 메시지 내의 본문 파트를 가리키는mid:참조를 제공합니다. Content-ID는 전역적으로 고유하도록 의도되었지만, 많은 저장소가 메시지 맥락 밖의 파트를 색인하지 않습니다. 더 긴mid:형식은 상호 운용성을 위해 그 맥락을 함께 전달합니다.

이것이 유사성과 주소 지정 가능성의 차이입니다. "세 번째 단락"을 가리키는 페이지 플래그는 편집 후 흐려질 수 있습니다. 패키지 밖을 가리키는 URL은 바뀌거나 사라질 수 있습니다. 범위가 지정된 식별자는 적어도 수신 응용 프로그램에게 어떤 객체가 명명되었는지, 어디서 해소할지 알려 줍니다. 그러나 식별자는 대상을 실행할 권한을 부여하지도 않고 대상이 신뢰할 수 있음을 증명하지도 않습니다. 식별, 무결성, 권한은 여전히 별개입니다.

집합체는 전송 중에도 온전해야 했다

RFC 2557은 복합 객체 기술을 운영상의 문제에 적용합니다. 이미지와 기타 보조 자원을 포함한 완전한 HTML 문서를 하나의 메시지로 보내는 것입니다. 그 결과는 text/html 루트를 가진multipart/related집합체이며, 자원은 Content-ID 또는 Content-Location으로 참조됩니다.

이 규격은 스테이플러 은유가 흐리게 만들었던 구분을 보존합니다. 집합체의 URI가 반드시 그 루트의 URI인 것은 아닙니다. Content-Location은 본문 파트에 레이블을 붙이면서도 그것을 전역적으로 검색 가능하게 만들지 않습니다. 기존 HTML은 링크를 다시 쓰지 않고 전달될 수 있습니다. 재작성은 메시지 무결성 검사를 무효화할 수 있기 때문입니다. 구조, 위치, 검색, 무결성은 서로 관련되지만, 어느 하나도 다른 것을 대체하지 않습니다.

그 결과는 전자 체결물만큼 시각적으로 매력적이지는 않지만 훨씬 더 유용합니다. 수신자는 루트, 보조 파트, 참조 메커니즘, 그것들을 처리하는 응용 프로그램을 알 수 있습니다. 집합체를 복사하면 정의된 관계를 보존할 수 있으며, 첨부 아이콘 표시는 더 이상 전체 계약을 짊어지도록 요구받지 않습니다.

최소 공통 계층은 장식이 아니라 의미론이다

Lu Heng의Running-Code Primacy는 공표가 구현, 검증, 배포, 채택을 통해 운영상으로 실현된다고 주장합니다. RFC 1927은 그 반대의 실험실 데모에 가깝습니다. 선언된 스테이플러는 수신자들이 같은 의미론을 구현하고 실제 연산을 통해 그것을 보존하지 않는 한 결합력을 갖지 못합니다.

함께 다루어지는 설계 규칙인Minimum Initial Specification은 모든 필드에 모호한 선택적 의미를 부여하라는 뜻이 아닙니다. 반드시 공통이어야 하는 것만 엄격하게 명시하라는 뜻입니다. 복합 문서의 경우 그 공통 계층에는 루트, 식별자, 관계 규칙, 무결성 경계, 알 수 없는 값에 대한 안전한 동작이 포함될 수 있습니다. 아이콘 색상, 데스크톱 조각상, 로컬 워크플로 취향은 로컬에 남을 수 있습니다.

상징적 계층과 실행 가능한 계층의 구분이 그림을 완성합니다. 스테이플러 아이콘은 상징적 권력입니다. 대상들이 함께 속한다고 사람을 설득합니다. 실행 가능한 권력은 소프트웨어가 분리를 거부하거나, 워크플로를 실행하거나, 자원을 삭제하거나, 참조를 권위 있는 것으로 취급할 때 나타납니다. 이 둘을 혼동하면 친절한 인터페이스가 검토되지 않은 제어 표면으로 변합니다.

따라서 RFC 1927의 최고의 농담은 컴퓨터가 사무용품을 필요로 했다는 것이 아닙니다. 하나의 익숙한 그림이 관계를 정의하는 어려운 작업을 없앨 수 있는 것처럼 보였다는 것입니다. 그렇게 될 수 없었습니다. 지속 가능한 시스템은 아이콘에게 설명을 맡기고, 명시적 의미론에게 결정을 맡깁니다.

출처

  1. RFC 1927 — Suggested Additional MIME Types for Associating Documents
  2. RFC Editor — RFC 1927 current record
  3. RFC Editor — RFC 1927 errata
  4. RFC 2046 — MIME Part Two: Media Types
  5. RFC 2183 — The Content-Disposition Header Field
  6. RFC 2387 — The MIME Multipart/Related Content-type
  7. RFC 2392 — Content-ID and Message-ID URLs
  8. RFC 2557 — MIME Encapsulation of Aggregate Documents
  9. Lu Heng — Running-Code Primacy
  10. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Lu Heng — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile