헤더는 33초라고 했다. 메시지는 아직 재생되지 않았다: RFC 2424

요약

• Content-Duration: 33은 메일 클라이언트가 미디어를 열지 않고도 발신자가 제공한 33초 미리보기를 표시할 수 있게 했다. 이 헤더는 시간 정보에 쉽게 접근하게 해 줄 뿐, 독립적으로 측정해 주지는 않았다.
• RFC 2424는 정확한 값이 필요하면 콘텐츠를 열어 재생해야 한다고 명시했고, 수신 측 표시 동작은 지역 구현 문제로 남겨 두었으며, 이 필드로 정확한 데이터 크기를 추론하는 것도 경고했다.

메시지는 아직 재생되지 않은 상태였다. 그런데도 그 숫자는 이미 자리하고 있었다:Content-Duration: 33. 작은 화면은 사용자가 첨부 파일을 열기 전에 음성 클립의 표시 길이를 보여줄 수 있었고, 클라이언트는 유용한 추정치를 표시하기 위해 오디오를 디코딩할 필요가 없었다. 편의성은 실제였다. 헤더 속 숫자와 미디어에 대한 관찰 사이의 간격도 마찬가지였다.

1998년 9월 표준 트랙(Standards Track)으로 발행된RFC 2424가 다루었던 바로 이 간결한 문제다. 이 RFC는 시간이 흐르는 콘텐츠, 즉 일반적으로 오디오나 비디오를 위한 MIME 헤더를 정의했다. 필드의 구문은 의도적으로 단순했다:Content-Duration:뒤에 1~10개의 십진수 숫자가 온다. 값은 초를 의미하며, 단위 태그는 없다. RFC의 예제에서 33은 33초를 뜻했다.

왜 이 주장을 별도의 헤더에 담았을까? 미디어 포맷은 자체적으로 재생 시간을 담고 있을 수도 있고, 데이터의 바이트 길이로부터 계산할 수도 있다. 어느 경로든 콘텐츠를 다루거나 그 인코딩을 이해해야 한다. MIME 헤더는 더 저렴한 경로를 제공한다: 메시지 소프트웨어가 바깥쪽 메시지 구조를 처리하면서 시간 값을 발견할 수 있는 자리에 놓는 것이다. 제약이 많은 음성사서함 환경에서는 단순한 MIME 또는 심지어 MIME이 아닌 데스크톱이 오디오를 열기 전에 메시지의 길이를 표시하는 데 도움이 될 수 있었다.

필드의 단순함은 그 권위의 성격도 드러낸다. RFC 2424는 이 값을 발신자가 결정한 것으로 규정한다. 문서는 재생 시간이 정확해야 한다고 말하지만, 즉시 그것이 의미할 수 있는 범위를 한정한다: 정확한 재생 시간은 콘텐츠를 열어 재생하기 전에는 알 수 없다는 것이다. 정확성이 중요하다면 문서는 후자의 방법을 가리킨다. 따라서 이 헤더는 측정 서비스가 아니다. 그것은 검증에 필요한 관찰보다 앞서, 쉬운 접근을 위해 제공된 휴대 가능한 주장이다.

이 구분은 보편적인 인터페이스를 강제하지 않았다. RFC는 수신함 헤더나 열린 오디오 첨부 파일 등 재생 시간을 표시할 수 있는 여러 자리를 나열한 뒤, 수신 측의 실제 사용은 지역 구현 문제라고 말한다. 표준은 필드와 그 의미를 정의했을 뿐, 모든 클라이언트가 그것을 표시하도록 요구하거나, 얼마나 두드러지게 표시할지 정하거나, 특정 클라이언트가 미디어를 올바르게 디코딩한다는 것을 증명하지 않았다. 표준화된 힌트는 어떤 단일 인터페이스 결정보다 더 멀리 전해지지만, 그 결정을 균일하게 만들지는 않는다.

Voice Profile for Internet Mail은 이 헤더에 구체적인 자리를 부여했다.audio/32KADPCM과 함께라면, 재생 시간은 기본 데스크톱이 오디오를 다루기 전에 음성 메시지의 길이를 파악하는 데 도움이 될 수 있었다. 그것은 누가 말했는지, 클립이 언제 녹음되었는지, 사용자가 파일을 열었는지, 끝까지 들었는지를 증명하는 것과는 다르다. 그런 사실들은, 존재한다면, 다른 곳에서 전달되거나 관찰되는 별개의 사실들이다.

이후 기록에는 연속성과 함께 넓어지는 틀이 모두 나타난다. 2004년 RFC 2424를 대체하기 위해 발행된RFC 3803은 편집 및 표지 문구 변경만을 했다고 말한다. 구문과, 발신자 값과 재생 기반의 정확성 사이의 구분은 그대로 남았다. 2005년에는RFC 4021이 본문 부분 콘텐츠의 재생 시간을 위한 표준 트랙 MIME 헤더 필드로Content-Duration을 등록했다. 이 등록은 헤더 레지스트리에서 필드를 찾기 쉽게 만들었을 뿐, 그 선언을 검증된 판독값으로 바꾸지는 않았다.

정보성 클라이언트 동작 문서인RFC 4024는 표시 문제를 더 명확히 했다. 텍스트 크기는 킬로바이트로, 음성 길이는 초로, 팩스 길이는 페이지로 표현될 수 있다. 이 문서는 음성 메시지 표시를 위해 주 오디오 파트의Content-Duration을 선호하면서도, 클라이언트가 여러 오디오 파트를 합산하는 것을 허용했다. 혼합 미디어의 경우 표시되는 “크기”를 주 콘텐츠 유형에 연결했다. 이들은 모두 클라이언트 화면에 관한 권고이지, 값이 측정되었거나 콘텐츠가 재생되었다는 보장이 아니다.

RFC 2424는 또한 어떤 속성을 미디어 바깥으로 옮기면 그 노출 범위도 달라진다는 점을 짚었다. 일부 환경에서는 헤더에 재생 시간을 명시적으로 표시하는 것 자체가 보안 문제가 될 수 있다. 그리고 정확한 데이터 크기를 확립하기 위해 재생 시간을 믿어서는 안 된다: 그러려면 데이터 자체를 검사해야 한다. 초와 바이트는 서로 다른 질문에 답한다. 발신자의 재생 시간 필드가 바이트 검사를 대신할 수 없는 것은, 바이트 수가 특정 디코더가 클립을 얼마나 오래 재생할지 증명할 수 없는 것과 마찬가지다.

역사적 교훈은 소박하지만 오래 지속된다. 표준은 기반이 되는 속성을 검증하기 쉽게 만들지 않고도 주장을 담고 표시하기 쉽게 만들 수 있다. RFC 2424는 양쪽을 모두 이름 짓는다: 편의를 위한 발신자 제공 시간, 그리고 정확성을 위한 열고 재생하기. 클라이언트는 후자가 일어나기 전에 전자를 표시할 수 있다. 필드도 표시도 증명하지 못하는 것은, 재생 시간이 실제 재생과 일치했는지, 메시지가 온전히 도착했는지, 누군가 들었는지이다. 헤더는 33초라고 말한다. 누군가 콘텐츠를 검사하기 전까지 근거는 거기서 멈춘다.