요약

  • RFC 3458은 메시지 전체와의 예상 상호작용을 위한 선택적인Message-Context필드 하나를 추가했을 뿐, MIME 파트를 재정의하거나 명시된 매체가 실제로 여전히 존재한다고 약속하지 않았습니다.
  • 잘못되었거나 알 수 없거나 오래된 컨텍스트는 로컬 처리에 영향을 줄 수 있었지만, 전송을 실패하게 하거나 필드가 없을 때보다 메시지를 덜 의미 있게 표시되게 하는 것은 허용되지 않았습니다.

하나의 메시지는 원래 매체보다 오래 남을 수 있었다

2003년의 인터넷 메일은 더 이상 단순한 편지 모양의 텍스트 스트림이 아니었습니다. 통합 메시징은 이메일, 팩스, 호출기 트래픽, 녹음된 음성, 복합 멀티미디어를 같은 수신 환경에 결합했습니다. MIME 유형만 보고는 발신자가 기대하는 상호작용이 항상 드러나지 않았습니다. 텍스트는 일반 이메일일 수도, 호출기 메모일 수도, 음성 메시지의 전사문일 수도 있었습니다. 큰 복합 객체는 어떤 아이콘이나 뷰어를 제공할지 결정하려고만 해도 살펴보는 데 비용이 들 수 있었습니다.

RFC 3458은 바로 그 좁은 모호성을 최상위 선택 필드 하나로 다뤘습니다.Message-Context는voice-message,fax-message,pager-message,multimedia-message,text-message,none같은 등록된 값을 담을 수 있었습니다. 이 필드는 최대 한 번만 나타날 수 있었고, 이름은 대소문자를 구분하지 않았으며, 생략은none을 의미했습니다.일반 텍스트,RFC Editor 기록,Datatracker 파일,문서 이력,참고 문헌,이후 인용,정오표 검색이 이 표준 기록의 경계를 정합니다.

결정적인 단어는 내용이 아니라 컨텍스트였습니다. 수신자는 이 선언을 사용해 뷰어나 아이콘을 고르고, 메시지를 그룹화하고, 받은 편지함을 정렬하고, 제한된 연결에서 표시할 자료를 줄이거나, 적절한 회신을 제안할 수 있었습니다. 그러한 편의 중 어느 것도 이 헤더를 오디오 파트, 팩스 이미지 또는 실행 가능한 객체가 실제로 존재한다는 증거로 만들지는 못했습니다.

변환은 불일치를 정상으로 만들었다

이 RFC가 든 가장 좋은 예는 게이트웨이를 통과하는 음성 메시지였습니다. 게이트웨이는 오디오를 제거하고 텍스트 전사문만 남길 수 있었습니다. 그 상호작용은 역사적으로 여전히 음성 메시징으로 이해될 수 있었지만, 수신 클라이언트에는 재생할 오디오가 없었습니다. 반대로 음성 컨텍스트를 주장하면서 팩스 내용만 도착할 수도 있었습니다. 클라이언트는 어느 쪽이든 자신이 받은 본문을 렌더링해야 했습니다.

이 규칙은 오류뿐 아니라 평범한 변환으로부터도 시스템을 보호했습니다.RFC 2822는 메시지 구문을 정의했습니다.RFC 2183은 본문 파트의 처리 방식을 다뤘습니다.RFC 2387과RFC 2557은 복합 구조를 설명했고,RFC 2423은 VPIM 컨텍스트를 제공했습니다. 이 인접한 메커니즘들은 서로 다른 질문에 답했습니다. Message-Context가 그들을 대체하지는 않았습니다.

가장 중요한 점은, 기형이거나 잘못된 분류가 전송을 거부하거나 표시를 포기할 이유가 아니었다는 것입니다. 수신자는 컨텍스트 필드가 도착하지 않은 것처럼 최소한 그만큼 의미 있게 내용을 보여야 했습니다. 단순 보존을 넘어선 전달은 사양의 범위 밖으로 남겨졌고, 이로써 오래된 값은 강제해야 할 진실이 아니라 관찰해야 할 상태가 되었습니다.

힌트는 권한 경계 아래에 머물러야 했다

보안 경고는 이 아키텍처를 명시적으로 만들었습니다. 애플리케이션과 유사한 컨텍스트 아래 도착한 프로그램은 헤더가 그렇게 말한다는 이유만으로 실행되어서는 안 됩니다. 악의적인 발신자는 자원을 소모하거나 처리를 빼돌리거나 주의를 끄는 클래스를 선택할 수 있었습니다. 이 필드는 발신자도 본문도 인증하지 않았고, 어떤 동작도 승인하지 않았으며, 전달을 증명하지 않았고, 긴급성이나 사람의 대응에 대해서도 신뢰할 수 있는 말을 하지 않았습니다.

RFC 3459는 MIME 본문 파트에 대한 중요 콘텐츠 매개변수를 별도로 정의했습니다. 이는 RFC 3458을 더 강하게 읽는 것이 아니라 서로 다른 제어 지점이었습니다.RFC 3938은 나중에 등록 정책을 개정했고,RFC 3864는 더 넓은 필드 등록 프레임워크를 제공했습니다. 현재의IANA 메시지 헤더 레지스트리는 이 할당을 기록할 뿐, 어떤 클라이언트가 그를 따랐는지 무시했는지 아니면 다시 썼는지는 기록하지 않습니다.

Lu Heng의 이후현실 층위 규율은 이 구분에 이름을 붙이는 데 도움이 됩니다. 선언된 컨텍스트와 수신된 본문은 서로 다른 종류의 사실입니다.실행 코드 우선 원칙은 실제 MIME 트리, 게이트웨이 변환, 폴백 렌더링으로 주의를 돌립니다.최소 초기 사양의 관점은 작은 선택 필드 하나가 MIME, 전달 또는 보안 정책을 흡수하지 않으면서도 조정을 돕는 이유를 설명합니다. 이들은 공개된 편집 관점이며, 저자들의 사적 의도에 대한 주장이 아닙니다.

따라서 RFC 3458은 승격을 거부함으로써 성공했습니다. 그 헤더는 수신자가 준비하는 데 도움을 줄 수 있었습니다. 그러나 실제로 도착한 것을 읽지 않아도 되게 만들 수는 결코 없었습니다.

출처