해결책
초기 인터넷 메일은 ASCII만 지원했기 때문에 메시지 본문이 모든 클라이언트가 동의하는 방식으로 이미지나 파일을 운반할 수 없었다. MIME(Multipurpose Internet Mail Extensions)은 이를 바꾸기 위해 고안되었다.
MIME은 카네기 멜런 대학의 Andrew Messaging System에서 크로스 플랫폼 데이터 형식으로 출발했으며, 공동 창시자인 Nathaniel Borenstein 등이 1992년 6월 RFC 1341로 처음 명세했다. 현재 버전은 1996년의 RFC 2045/2046/2047 세트이다.
그 설계는 의도적으로 작았다. Content-Type 헤더는 해당 부분이 무엇인지 명명하고, Content-Transfer-Encoding은 바이너리를 ASCII로 변환하며, 멀티파트 경계는 하나의 본문이 여러 부분을 담을 수 있게 한다. 메시지는 여전히 이전과 같이 SMTP를 통해 전송된다.
이 확장은 헤더 기반이며 선택 사항이었기 때문에 각 클라이언트가 자체 일정에 따라 지원을 추가할 수 있었고, MIME은 빠르게 첨부 파일과 리치 텍스트 이메일을 보내는 표준 방식이 되었으며, 나중에는 웹 자체의 콘텐츠 유형 개념의 기반이 되었다.
이룬 것
본문이 무엇인지 알려주는 헤더를 추가한다
통한 이유
콘텐츠 유형 헤더는 수신자에게 해당 부분이 무엇인지 알려주므로 규칙에 따라 디코딩할 수 있다
base64는 임의의 바이너리가 ASCII 전용 전송을 통과할 수 있게 한다
멀티파트 경계는 하나의 메시지가 텍스트와 첨부 파일을 함께 담을 수 있게 한다
변경이 헤더 수준이었기 때문에 도입에 공통 전환이 필요하지 않았다
널리 배포된 시스템을 확장하려면 새로운 시스템이 아니라 작고 선택적인 구조 조각을 추가하라. 페이로드가 무엇인지 알려주는 헤더가 있으면 각 구현자가 자체적으로 도입할 수 있다.
그 후
MIME은 이메일 첨부 파일의 보편적인 컨테이너가 되었고, Content-Type 헤더가 웹 리소스를 설명하기 위해 그 아이디어를 차용한 이유이기도 하다. 원래 명세는 표현(presentation)에 대해 빈약했기 때문에 RFC 2183에서 Content-Disposition이 추가되었다. 실제로 많은 클라이언트는 여전히 표준의 권고보다 자체 로직을 사용하여 표시할 부분을 선택한다.
근거 확인하기
출처
- Multipurpose Internet Mail Extensions (MIME) Part One (RFC 2045) IETF / rfc-editor.org · rfc-editor.org
- MIME — Wikipedia Wikipedia · en.wikipedia.org