요약

  • RFC 2447은 MIME 메시지에서 기계 판독 가능한 캘린더 객체가 위치하는 자리와 그 일정 조율 방식이 식별되는 방법을 정의함으로써 iTIP을 이메일에 결합했습니다.
  • 일반 언어로 된 대안 표현은 호환성을 높였지만, 이는 동일한 일정 객체를 다른 방식으로 보여준 것이지 경쟁하는 별도의 이벤트가 아니었습니다.

메일 패킷에 캘린더 계층이 생기다

iMIP 이전에는 “초대장을 이메일로 보낸다”는 말이 사용자 인터페이스 선택처럼 들렸습니다. RFC 2447은 이것을 프로토콜의 문제로 만들었습니다. iTIP은 이미 전송 수단과 독립적으로 일정 조율 동작을 기술하고 있었고, iCalendar는 이벤트 데이터를 기술했습니다. iMIP은 그 빠져 있는 가교를 제공했습니다. 즉, 인터넷 메시지 및 MIME 규칙에 따라 캘린더 객체를 패키징한 뒤 이메일로 운반하는 방식입니다. 이 분리가 중요했습니다. iMIP은 메일 소프트웨어가 바뀔 때마다 새로운 일정 조율 동작을 발명하지 않았습니다. 캘린더상의 의미가 다른 곳에서 정의된 객체를 메일 시스템이 운반하는 방법을 정의했을 뿐입니다.

패키지는 여러 계층으로 이루어져 있었습니다. 일반 메시지 헤더는 메시지를 메일 인프라를 통해 전송했습니다. MIME은 본문 부분들을 식별하고 구분했습니다. 그중 하나인text/calendar는 일정 조율 프로토콜이 사용하는 iCalendar 객체를 담았습니다. 이 세 계층을 하나의 “초대장”으로 취급하면, 어떤 결정이 어디에 인코딩되어 있는지, 캘린더를 인식하는 에이전트가 어느 구성 요소를 처리해야 하는지가 가려집니다.

RFC 2447은 MIME 부분에method매개변수를 부여하고, 그 값이 캘린더 객체의METHOD속성과 일치하도록 요구했습니다. 이는 작지만 두 문법 사이를 잇는 결과가 큰 결합이었습니다. 메일 파서는 MIME 경계에서 일정 조율 메시지를 식별할 수 있고, 캘린더 파서는 그 안의 객체를 읽을 수 있습니다. 바깥의 method와 안쪽의 method가 어긋나면 메시지는 더 이상 하나의 모호하지 않은 일정 지시를 갖지 않습니다. 서로 다른 method를 가진 여러 캘린더 객체가 하나의 메시지에 담길 때, 사양은 이들을 하나의 객체인 것처럼 다루지 않고multipart/mixed안의 별개text/calendar엔티티로 분리했습니다.

읽을 수 있는 사본은 또 다른 이벤트가 아니었다

MIME은 또한 메시지 하나에 기계 판독 가능한 캘린더 부분과 함께 사람이 읽을 수 있는 설명을 담을 수 있게 했습니다. 그 목적은 실용적이었습니다. 캘린더 기능이 없는 메일 사용자 에이전트도 일반 텍스트로 누가, 언제, 어디서인지를 표시할 수 있어야 했습니다. 기능을 갖춘 에이전트는text/calendar를 처리할 수 있습니다. 두 부분은 서로 다른 독자를 위한 것이었지만, 표준은 이들을 하나의 일정 조율 메시지의 대체 표현으로 다뤘습니다.

이 구분은 유혹적인 오용을 배제합니다.multipart/alternative는 서로 다른 시작 시간 두 개나 서로 경쟁하는 두 VEVENT를 협상하는 형식이 아니었습니다. 기계 판독 가능한 대안들이 서로 다른 가능한 회의를 기술한다면, 수신자는 메일이 선택지를 제공하는지, 정정을 담고 있는지, 아니면 우연히 스스로 모순되는지 알 수 없습니다. 동작은 iTIP의 일정 조율 방식(method)에 속하고, MIME 대안은 표현을 위한 것입니다. 서로 다른 method를 가진 별개 객체는 별개의 캘린더 부분과 mixed 패키지가 필요했습니다.

이것은 범위가 좁은 상호운용성 협상이었습니다. 이메일은 이미 익숙한 저장 후 전달(store-and-forward) 채널을 제공했고, MIME은 형식이 지정된 콘텐츠를 텍스트와 첨부물 옆에 담아 운반하는 방법을 제공했습니다. 어느 계층도 수신자가 메시지를 열었는지, 호환되는 캘린더 에이전트를 갖고 있는지, 객체를 적용했는지를 보장하지 않습니다. “화요일 오후 세 시”라는 읽을 수 있는 문장은 사람에게 도움이 될 수 있지만 캘린더가 변경되었다는 증거가 되지는 못합니다. 반대로, 문법적으로 유효한 캘린더 부분은 주변 산문이 무시되더라도 처리될 수 있습니다. 전달, 표시, 캘린더 상태는 서로 다른 관측으로 남았습니다.

인코딩 규칙은 전송 중 객체를 보존했다

MIME의 charset 및 transfer-encoding 규칙은 또 다른 경계를 다뤘습니다. 즉, 메일 전송을 통과하는 동안 캘린더 텍스트를 어떻게 보존할 것인가입니다. RFC 2447은 객체가 US-ASCII 범위 밖의 문자를 포함할 때 charset 선언을 요구했고, 선택한 메일 경로가 직접 운반할 수 없는 콘텐츠에 대한 전송 인코딩을 기술했습니다. RFC 6047은 이후 더 새로운 메시지 형식 및 S/MIME 사양에 맞춰 이 결합을 갱신하고 8비트 클린 전송 사례를 명확히 했습니다. 이 규칙들은 전송 경로를 넘어서는 표현에 관한 것이며, 날짜를 검증하거나 주최자를 승인하거나 성공적인 전달을 증명하지 않습니다.

첨부 파일은 덜 명백한 방식으로 동일한 경계를 드러냈습니다. 캘린더 속성은 콘텐츠 ID나 메시지 ID로 자료를 참조할 수 있었습니다. RFC 2447은 가능한 한 참조된 MIME 부분을 캘린더 객체와 함께 운반하도록 권고했습니다. 수신자가 다른 곳에서 참조된 객체를 가져올 접근 권한이나 인가를 갖지 못할 수 있기 때문입니다. 참조는 위치 지정자이지 사본도 권한 부여도 아닙니다. MIME 패키지가 이벤트와 그 자료 사이의 관계를 보존하려면, 필요한 부분이 함께 이동하거나 수신자가 별도의 작동하는 접근 경로를 갖고 있어야 했습니다.

봉투의 가시적 신원 필드도 마찬가지로 한정되어 있었습니다. 전달(forwarding)이 일어나면 현재의Sender가 캘린더의Organizer일 필요는 없습니다. 사용자 에이전트가 캘린더 역할을Reply-To로 번역하도록 요구되지도 않았습니다. 그래서 RFC 2447은 구현이 메일 헤더에서 역할을 추론하지 않고 캘린더 객체 안의ORGANIZER와ATTENDEE를 살펴보도록 지시했습니다. 이 표준은 MIME 보안 multipart를 이용한 인증을 논의했고, RFC 6047은 나중에 인증에 S/MIME을 요구했습니다. 보호된 부분의 검증된 서명은 구성된 신뢰 절차 하에서 그 부분에 서명한 사람이 누구인지를 확립할 수 있습니다. 그러나 메시지가 의도한 수신자에게 도달했는지, 수신자의 캘린더가 이를 수용했는지, 또는 그 사람이 참석에 동의했는지는 확립하지 않습니다.

표준의 계보는 명확합니다. RFC 2447은 1998년 11월 표준 트랙(Standards Track) 이메일 결합으로 출판되었고 2010년 RFC 6047에 의해 대체되었습니다. 이 역사는 메시지 형식과 보안 환경이 바뀜에 따라 프로토콜 경계가 개정되었음을 보여줍니다. 특정 캘린더 제품이 어느 버전을 얼마나 널리 구현했는지에 대한 증거는 아닙니다. 지속되는 교훈은 구조에 관한 것입니다. 일정 조율 의미를 캘린더 객체에 넣고, MIME 경계에서 그 패키징을 기술하며, 어느 쪽도 메일 봉투나 수신자의 최종 상태와 혼동하지 말라는 것입니다.

출처