요약

  • RFC 1874는 사람이 SGML 인식 소프트웨어 없이도 전반적인 의미를 얻을 수 있는지에 따라text/sgml과application/sgml을 구분했다. 이는 대체 규칙이었지, 콘텐츠가 무해하다는 증명이 아니었다.
  • 미디어 타입, charset,SGML-bctf변환, 그리고 별도로 참조되는SGML-boot파트는 서로 다른 질문에 답했다. 하나를 인식했다고 해서 나머지의 올바른 디코딩이나 파싱이 증명되지 않았다.
  • RFC는 SGML 처리가 시스템 수준 명령을 허용할 수 있다고 경고했다. 이후 XML 미디어 타입들은 공유 문법 계열이 프로세서, 엔티티 역할, 보안 정책을 상호 교환 가능하게 만들지 않으면서도 디스패치를 안내할 수 있음을 보여주었다.

하나의 문서, 두 명의 독자

SGML 엔티티는 평범해 보이는 줄들의 연속으로 메일 클라이언트에 도착할 수 있었다. 한 독자는 MIME 텍스트만 다룰 줄 아는 소프트웨어를 가진 사람이었다. 다른 독자는 선언, 엔티티, 처리 지시문을 해석할 준비가 된 SGML 시스템이었다. 둘은 같은 옥텟을 받았지만 같은 행위를 수행하지 않았다.

1995년 12월에 실험(Experimental) 표준으로 공개된RFC 1874는 사람에게 여전히 의미가 전달되는 엔티티를text/sgml로 분류했다. 나머지는 모두application/sgml에 속했다. 텍스트 형식에서는 레코드 시작 및 레코드 끝 문자로 경계가 정해진 각 SGML 레코드가 MIME 본문의 한 줄에 대응해야 했다.

이 요구사항은 저기능 경로를 보존했다. SGML 지원이 없는 클라이언트는 본문을 텍스트로 취급하면서도 그 전반적인 의미를 드러낼 수 있었다. 발신자는 모든 태그가 우아하게 사라지고, 모든 엔티티 참조가 해석되고, 모든 응용 수준 의미가 살아남는다고 약속한 것이 아니었다. “읽을 수 있다”는 것은 전문 해석을 거부한 뒤에도 남아 있는 것을 말했다.

이 구분은 MIME의 일반 아키텍처를 따랐다.RFC 2046은 최상위 타입이 서브타입을 모를 때도 응용 프로그램을 안내한다고 설명했다. 알 수 없는 텍스트는 흔히 원시 데이터로 표시될 수 있지만, 알 수 없는 이미지나 오디오는 보통 그렇지 않다. 따라서 텍스트 서브타입은 전용 프로그램 없이도 독자에게 대략적인 개념을 제공해야 했다.

이는 통제된 호환성 약속이었다. 더 풍부한 구조를 처리하는 것이 안전하다는 선언이 아니었다.

하나의 Content-Type이 담은 여러 독립 질문

두 SGML 서브타입은 파라미터를 공유했지만, 파라미터가 하나의 결론으로 합쳐지지는 않았다.text/sgml의 경우charset은 SGML을 지원하지 않는 수신자가 합리적인 텍스트 대체물을 표시하도록 도왔다. SGML 지원 시스템은 다른 목적을 위해SGML-bctf, 즉 비트 조합 변환 형식을 사용할 것으로 기대되었다. 그 목적은 SGML의 논리적 문자 번호를 전송된 옥텟 스트림으로 번역하는 것이었다.

RFC 1874는 identity와 여러 고정 또는 가변 변환을 나열했다. 수신자는 서브타입을 인식하면서도 명명된 변환을 갖고 있지 않을 수 있었다. 전송 바이트는 디코딩하면서 잘못된 SGML 문자 매핑을 선택할 수도 있었다. 파라미터의 존재는 발신자의 지시를 기록했지, 수신자의 구현이나 결과를 기록하지 않았다.

세 번째 계층은 더 이례적이었다.SGML-boot는 부트 정보 자체를 담지 않았다. 다른 MIME 본문 파트의 Content-ID를 담았고, 그 파트는application/octet-stream객체로서 SGML 선언의 문자 번호를 매핑하는 정수 삼중항들을 보관했다. 부트 파트는 문서 엔티티에만 관련이 있었다.

따라서 참조가 획득보다 앞섰다. 주변 메시지가 의도된 파트를 여전히 포함해야 했다. 수신자는 올바른 Content-ID를 찾고, 그 바이트를 보존하고, 삼중항을 해석하고, 이를 사용해 선언을 읽어야 했다. 잘 구성된 파라미터는 누락된 파트, 중복 식별자, 지원되지 않는 매핑, 여전히 실패하는 선언과 공존할 수 있었다.

RFC 1590은 인터넷에 미디어 타입을 등록하는 공개 절차를 제공했다. 등록은 이름과 처리 요구사항을 검색 가능하게 만들었다. 그러나 전송되는 개별 객체를 검사하거나 수신 프로그램을 인증하지는 않았다. 레지스트리는 레이블이 무엇을 뜻하도록 규정되었는지 답했을 뿐, 특정 레이블이 도착한 뒤 무슨 일이 일어나는지 답하지 않았다.

텍스트 레이블이 능동적 권한을 제거하지는 않았다

RFC 1874는 가장 날카로운 경계를 보안 섹션에 두었다. SGML 엔티티는 단순히 표시되는 것이 아니라 파싱되고 처리되었다. 일부 시스템은 명시적인 시스템 수준 명령을 허용할 수 있었다. 표시나 조판을 위한 처리 지시문은 PostScript와 유사한 위험을 지닐 수 있었다.

이 경고가 중요한 이유는text/sgml이 안전 분류처럼 들릴 수 있기 때문이다. 그렇지 않았다. 최상위 타입은 대체 가독성을 설명했다. 수신자가 SGML 프로세서를 가동하는 순간, 다른 권한이 문제가 되었다. 프로그램이 파일에 접근할 수 있는지, 명령을 시작할 수 있는지, 외부 참조를 따라갈 수 있는지, 표시 환경을 변경할 수 있는지가 그것이었다.

한 사용자는 해석되지 않은 줄을 안전하게 읽으면서 구조를 처리하는 데에는 위험할 수 있었다. 다른 사용자는 모든 능동적 지시문을 차단하면서도 문서 트리를 올바르게 파싱할 수 있었다. 세 번째는 문자 매핑을 재구성하지 못해 파싱 이전에 실패할 수도 있었다. 이 결과들은 같은 영수증으로 요약될 수 없다.

MIME은 또한 구현체가 인식하지 못하는 파라미터를 무시하도록 요구했다. 이 규칙은 확장성을 보호했지만 또 하나의 분기점을 만들었다.SGML-boot를 무시하는 것은 일반 MIME 소프트웨어에는 올바른 동작일 수 있지만, 부트 맵에 의존하는 SGML 문서에는 불충분한 동작이었다. 봉투 수준의 호환성이 응용 수준의 충실성을 증명하지 않았다.

XML이 보여준 계열 유사성의 한계

3년 뒤RFC 2376은text/xml과application/xml을 등록했다. XML은 SGML의 부분집합이었지만, 그 RFC는 SGML 레이블의 재사용을 거부했다. 많은 XML 프로그램은 SGML의 더 큰 기능 집합을 처리할 수 없었다. SGML 프로그램은 XML을 항상 처리할 수 없었는데, XML이 나중의 SGML 교정 사항을 사용하기 때문이었다. SGML 변환 및 부트 파라미터는 XML과 무관했고 모호성을 초래할 수 있었다.

이는 이름에 의한 상속에 반하는 증거였다. “부분집합”은 언어 관계를 설명했다. 그것이 설치된 프로세서가 두 언어를 모두 수용한다거나, 부모 계열의 파라미터가 의미를 유지한다는 것을 증명하지 않았다.

RFC 3023은 XML 작업을 확장하고 응용별 형식을 위한+xml접미사를 확립했다. 접미사는 일반 도구에 문법 단서를 제공하면서, 완전한 미디어 타입이 도메인 의미를 담을 수 있게 했다.RFC 6838은 이후 인코딩, 상호 운용성, 프래그먼트 및 보안 고려사항을 포함하는 구조화 문법 접미사의 등록을 정식화했다.

이 설계는 권한을 지역화했다. 접미사는 일반 파서를 시도해볼 근거가 될 수 있다. 그러나 모든 일반 변환을 승인하거나 특정 미디어 타입의 규칙을 지울 수는 없다.

RFC 7303은 이 구분을 명시적으로 만들었다. 소프트웨어는+xml을 인지하고, 프로세서를 호출하여 XML 가정을 검증한 뒤, 특정 타입의 규칙에 따라 계속할 수 있었다. 이 RFC는 또한 일반 XML 처리가 부적절할 때 설계자가 접미사를 생략할 수 있도록 허용했다. 문법 신호조차 자동 디스패치로부터의 탈출로를 함께 지녔다.

RFC 7303은 문서 엔티티, 외부 DTD 서브셋, 외부 파싱 엔티티, 외부 파라미터 엔티티를 구분했다. 이들은 XML 문법을 공유했지만 자유롭게 상호 교환되지 않았다. 레이블은 엔티티의 계보가 아니라 역할을 보존해야 했다.

역사적 영수증은 좁게 유지되어야 했다

RFC 1874 객체에 대한 정직한 기록은 사슬 형태다. 발신자가 타입을 선택했다. 레지스트리가 이를 정의했다. 수신자가 바이트를 받았다. MIME 소프트웨어가 헤더를 파싱했다. 대체 경로가 줄들을 보여줬거나, SGML 경로가 변환을 적용했다. 부트 참조가 해석되었다. 선언이 파싱되었다. 능동적 지시문이 허용되거나 차단되었다. 응용이 결과물을 만들어냈다.

각 진술은 참이면서 다음 진술은 거짓일 수 있다. 스크린샷은 한 화면이 보여준 것을 증명하지, 어떤 BCTF가 적용되었는지 증명하지 않는다. 파스 트리는 문법을 증명하지, 안전한 명령 정책을 증명하지 않는다. 등록된 타입은 공개를 증명하지, 지원을 증명하지 않는다. Content-ID는 참조가 작성되었음을 증명하지, 그 대상이 메시지를 따라왔다는 것을 증명하지 않는다.

RFC 1874의 지속적 기여는 두 미디어 타입이 구조화 텍스트의 최종 답이 되었다는 것이 아니었다. 이후 XML 분리가 보여주듯 그렇지 않았다. 그 가치는 드러낸 경계에 있다. 사람이 읽을 수 있는 대체 경로와 기계 처리 권한은 같은 문서에서 출발하더라도 서로 다른 계층을 점유한다.

출처와 한계

RFC 1590, 1874, 2046은 등록, SGML 파라미터, 대체 경로 및 MIME 타입 규칙을 확립한다. RFC 2376, 3023, 6838, 7303은 이후의 XML 분리와 구조화 접미사 모델을 확립한다. 이 출처들은 공개된 명세와 명시된 위험을 증명한다. 채택률, 특정 제품의 동작, 성공적인 파싱, 실제 명령 실행, 익스플로잇, 사용자 피해, 현재 배포 현황은 증명하지 않는다.