요약

  • RFC 3459는 개별 MIME 바디 파트에Handling=REQUIRED|OPTIONAL표시를 붙였다. REQUIRED 파트를 통과시키지 못하면 메시지 전체가 실패하며, OPTIONAL 파트는 조용히 사라져도 전송 실패로 이어지지 않는다.
  • 표시가 없거나 알 수 없는 값은 REQUIRED로 취급되며, 서명·암호화 래퍼, 제어 객체, 페이로드에 표시가 놓이는 위치가 게이트웨이가 보호된 콘텐츠를 변환할 수 있는지, 아니면 거부해야 하는지를 결정했다.

부분 전송에는 발신자 측 계약이 필요했다

일반 인터넷 메일은 MIME을 처리할 수 있는 수신자가 렌더러가 없더라도 모든 바디 파트를 보존하거나 노출할 것을 기대했다. 음성 메시징 시스템은 더 좁은 현실을 가질 수 있었다. 음성과 팩스는 저장하더라도 워드프로세서 첨부 파일이나 동영상은 처리하지 못할 수 있다. 따라서 콘텐츠 게이트웨이는 수신 단말의 능력을 알고 있었고, 때로 단말이 받아들일 수 없는 것을 제거했다.

2003년 1월에 발표된RFC 3459는 이러한 변환을 명시적으로 만들었다.일반 텍스트,RFC Editor 기록,Datatracker 파일,문서 이력,참고 문헌,이후 인용,정오표 검색이 표준 기록을 구성한다. 이 메커니즘은 Handling 매개변수를 ISUP/QSIG 전송에서 분리함으로써RFC 3204를 갱신했다.

Content-Disposition매개변수에 놓인REQUIRED는 해당 파트를 통과시킬 수 없다면 발신자가 메시지를 전송된 것으로 간주하지 않는다는 뜻이었다. 이런 파트 하나가 실패하면 메시지 전체가 실패했다.OPTIONAL은 게이트웨이가 조용히 파트를 삭제할 수 있으며, REQUIRED 파트도 실패하지 않는 한 전송 실패를 발생시켜서는 안 된다는 뜻이었다.

이 용어들은 감정적이거나 사업적인 중요도를 순위화하지 않았다. 변환 권한과 실패의 귀속을 배분했다. 사용자 에이전트가 발신자 모르게 숨겨진 보조 파트를 삽입했을 수 있으므로, 이를 optional로 표시하면 발신자가 신경 쓰지 않는 첨부 파일 때문에 음성 시스템이 유용한 음성을 거부하는 일을 막을 수 있었다.

침묵, 실패, 통지는 별개의 결정이었다

기본값은 의도적으로 보수적이었다. 표시되지 않은 파트는 REQUIRED였고, 인식되지 않는 미래의 값 역시 REQUIRED로 취급해야 했다. 구형 게이트웨이는 기존 MIME 규칙에 따라 알 수 없는 Content-Disposition 매개변수를 무시할 수 있었으나, 신형 게이트웨이는 새 의미를 이해하지 못하는 콘텐츠를 조용히 버리는 대신 실패로 닫혔다(fail closed).RFC 2045가 MIME 기반을 제공했고,RFC 2421은 제약된 수신자를 동기로 만든 음성 메시징 프로파일 맥락을 보여준다.

criticality 자체는 수신 확인을 요청하지 않았다. SMTP 전송 통지는 여전히RFC 3461을 따랐고, 메시지 처리 통지는RFC 3798을 따랐으며, 유형을 저장하거나 렌더링하지 못할 때는RFC 3463의 5.6.1 코드를 사용할 수 있었다. 최종 전송 전에 작동하는 게이트웨이는 DSN을 생성할 수 있었다. 전송 후 사용자 에이전트로 작동하는 구성 요소는 MDN을 생성할 수 있었다. SIP는 RFC 3204 사례의 415를 포함한 상태 응답을 돌려주었다. 수신 확인은 위상과 역할이 결정했지, REQUIRED 표시만으로는 결정되지 않았다.

암호화 래퍼는 위치 자체를 정책의 일부로 만들었다

가장 중대한 규칙은RFC 1847의 multipart 보안에 관한 것이었다.multipart/signed인클로저를 REQUIRED로 표시하면 그대로의 통과와 진정한 종단 간 검증을 요구했다. 검증할 수 없는 단말은 거부를 강제했다. 서명 제어 객체를 REQUIRED로 표시하면 유능한 게이트웨이가 전달 전에 검증할 수 있었지만, 검증 실패 역시 거부를 강제했다. 서명 데이터가 OPTIONAL이고 인클로저된 본문이 REQUIRED라면, 게이트웨이는 검증 불능 단말을 위해 서명 정보를 벗겨낼 수 있었으나 검증과 변조 표시는 강력히 권고되는 대상으로 남았다.RFC 2480이 관련 disposition 지침을 제공했다.

암호화는 같은 권한 관계를 더 선명하게 드러냈다. REQUIRED 암호화 제어 객체는 종단 간 암호화를 요구했다. OPTIONAL이라면, 권한을 가진 유능한 게이트웨이가 복호화해 평문을 복호화 불능 단말로 전달할 수 있었다. 이 허용은 발신자가 표시를 그곳에 놓았기 때문에 존재했다. 암호화된 데이터 안에 숨겨진 표시는 게이트웨이가 먼저 복호화하지 않으면 발견하기 어려우므로, 표시되지 않은 암호화 자료는 기본적으로 REQUIRED로 남았다.

이는 게이트웨이가 신뢰할 수 있다는 일반적 약속이 아니었다. 이는 표준을 준수하는 게이트웨이가 메시지 구조와 수신자 능력을 모두 알고 난 뒤 무엇을 할 수 있는지에 대한 규칙이었다.RFC 3238의 OPES 논의가 더 넓은 책임성 배경을 제공했다. 변환에는 보이지 않는 수정이 아니라 동의, 통지 의미론, 비차단 동작이 필요했다.

Lu Heng의 후속현실 계층 원칙은 네 가지 수신 확인을 구분하는 데 도움이 된다. 발신자의 표시, 게이트웨이의 능력 주장, 실제 수행된 변환, 그리고 반환된 결과이다.running-code 우선성은 위안이 되는 표지가 아니라 게이트웨이 전후의 MIME 트리에 주의를 돌리도록 한다. 이는 후속 편집적 관점이지, RFC 저자의 사적 의도에 대한 증거가 아니다.

RFC 3459는 부분 전송을 보이지 않는 사고에서 결과의 명시적 배분으로 바꾸었다. optional 파트는 사라져도 전송은 여전히 성공할 수 있었다. required 파트는 아주 작을 수 있지만, 그 손실은 메시지 전체를 무효로 만들었다.

출처