요약

  • RFC 2987은charset과language를 동등성 비교되는 미디어 특성으로 등록했지만, 첫 번째는 대개 기기 역량, 두 번째는 대개 사용자 선호라고 규정했다.
  • 대표 소문자 charset 이름과 전체 토큰 언어 매칭은 모호성을 줄였지만, 디코딩, 렌더링, 음성 품질 또는 이해를 입증하지는 않았다.
  • 품질 가중치는 국소적 결정 안에서 술어를 순위화한 것이며, 선택된 표현, 사용자의 만족 또는 서비스 결과에 대한 영수증이 아니었다.

나란히 놓인 두 등록

RFC 2987은 짧은 문서다. 대부분의 페이지는 등록 양식이다. 이 겉보기 소박함 때문에 문서의 핵심 결정을 놓치기 쉽다.

첫 번째 양식은charset(OID1.3.6.1.8.1.31)을 특정 등록된 문자 집합을 표시할 수 있는 능력으로 등록했다. 두 번째는language(OID1.3.6.1.8.1.32)를 특정 인간 언어를 표시할 수 있는 능력으로 등록했다. 두 값 모두 토큰이었다. 둘 다 동등성 비교만 가능했고, 두 비교 모두 대소문자를 무시했다. 두 예제 모두q가중치를 갖는 OR 표현식을 사용했다.

양식이 나란히 보인 이유는 RFC 2506이 전송·프로토콜 중립적인 미디어 특성 네임스페이스를 만들었기 때문이다. 협상 메커니즘은 응용마다 새 이름을 만들지 않고도 표현에 대한 단언을 운반할 수 있었다. RFC 2533은 특성 술어를 결합하고 품질 값을 붙이는 대수를 제공했다. 등록은 이 어휘를 이동 가능하게 만들었다.

그러나 이동 가능한 어휘가 곧 이동 가능한 의미는 아니었다. RFC 2987은 등록 자체에 의미적 비대칭을 직접 삽입했다.

문서는 말하기를, 대부분의 기기에서charset은 대개 역량이라고 했다. 기기는 자신이 모르는 문자 집합의 텍스트를 지능적으로 처리할 수 없다. 반면language는 대개 요구 사항이 아니라 선호였다. 문서는 '표시(display)'를 가장 흔히 컴퓨터 음성으로 상정했지만, 이 할당은 더 넓다. 언어 선택은 보통 기계가 파싱할 수 있는 물리적 사실이 아니라 사용자가 무엇을 원하는지를 표현한다.

따라서 하나의 문법이 서로 다른 두 종류의 제약을 담았다.

디코더 한계는 투표가 아니다

charset 예제는utf-8을 1.0,iso-8859-1을 0.9,utf-16을 0.5로 순위화했다. 이 숫자들을 세 가지 취향으로 읽고 싶은 유혹이 있다. 그러나 등록은 그런 독법을 경고한다.

기기에 선택된 디코더가 없다면 순위를 매길 의미 있는 출력 자체가 없을 수 있다. 술어가 이겼다고 해서 바이트가 텍스트가 되는 것은 아니다. 성공적으로 디코딩된 뒤에도 글꼴이 없을 수 있다. 렌더러가 실패할 수 있다. 유효한 글리프 열이 사용자에게 여전히 이해 불가능할 수 있다. 그러나 첫 번째 경계는 선호보다 더 단단하다. 디코더가 존재하고 수신된 표현을 받아들여야 한다.

RFC 2913은type을 별도의 미디어 특성으로 등록했다.charset을 미디어 타입 토큰 밖에 두는 것은 그 경계를 보이게 했다. 시스템은text/plain을 지원하면서 텍스트의 모든 인코딩을 지원하지 않을 수 있다. 표현 타입과 문자 인코딩은 관련된 주장이지 하나의 영수증이 아니었다.

RFC 2987은 또한 특성 표현식에서 charset 별칭을 쓰지 말 것을 저자에게 요청했다. RFC 2978은 하나의 charset이 여러 등록 이름을 가질 수 있도록 하되 대표 이름을 하나 두고 각 이름이 단 하나의 charset만 식별하도록 했다. 조작 도구는 별칭을 그 대표 이름으로 정규화할 수 있다. 한쪽이 별칭을 순위화하고 다른 쪽이 대표 철자를 순위화하면, 보존하려던 표현식이 예상치 않게 바뀔 수 있었다.

따라서 대표 소문자 이름은 상호운용성 규율이었다. 그것은 디코더를 보증하지 않았다. 정준 철자는 명명 불일치를 줄였을 뿐, 실행 중인 코드가 명명된 매핑을 올바르게 구현했음을 증명하지 않았다.

등록은 또 하나의 안전장치를 추가했다. 문자열 데이터를 처리할 수 있는 역량을 주장할 때는 charset 단언이 동반되어야 한다. 인코딩을 명명하지 않고 '텍스트'를 주장하면 수신자는 바이트를 문자로 바꾸는 가장 기본적인 전제조건을 검사할 수 없다.

언어 선호는 기계의 벽이 아니다

언어 예제는no-nynorsk,no-bokmaal,i-sami-no를 순위화했다. 여기서 같은 동등성 연산자가 다른 목적을 수행했다.

RFC 1766은 언어 태그를 기본 태그와 선택적 서브태그로 구성하되, 응용에게 완전한 태그를 하나의 토큰으로 취급하라고 지시했다. 서브태그는 행정적 것이었다. 범용 추론 트리가 아니었고, 공유 접두사가 상호 이해를 보장하지 않았다. RFC 2987은 이 운용 규칙을 반복했다. 전체 토큰을 대소문자 무시하고 비교하며, 비교에서 서브태그를 사용하지 말 것.

이 규칙은 협상자가 문자열 구조로부터 언어적 권위를 만들어내는 것을 막았다. 두 개의 더 긴 태그 안에서no가 매칭되었다고 해서 어느 쪽이 특정 독자나 청자를 만족시키는지 증명되지 않는다. 언어 태그는 등록 체계 아래에서 하나의 옵션을 명명했다. 문해력, 방언 익숙함, 발음, 접근성, 문화적 적합성을 측정하지 않았다.

그럼에도 언어는 대개 요구 사항이 아니라 선호였다. 실패한 동등성 테스트를 기기 무능으로 취급하면, 사용자가 '아무것도 없는 것보다는' 받고 싶어하는 콘텐츠를 버릴 수 있다. 선호를 무의미한 것으로 취급하면 사용자가 사용할 수 없는 언어를 반복적으로 전달할 수 있다. 올바른 대응은 국소 정책, 이용 가능한 변형, 사용자가 명시한 우선순위에 달려 있었다.

특성 표현식은 그 정책을 결정하지 않았다. 입력을 검사 가능하게 만들었을 뿐이다.

품질 값이 보증할 수 없는 것

RFC 2533은 품질 값이 술어를 한정하도록 허용했고, 한정되지 않은 술어에는 기본 품질 1을 부여했다. 모든 선호를 결합하는 하나의 보편적 방식을 정의하는 것은 의도적으로 피했다. 서로 다른 응용은 서로 다른 선택 규칙을 필요로 할 수 있었다.

이 한계가 중요하다. 하나의 언어에 붙은q=1.0은 특정 표현식 안에서 그 술어가 높게 순위화되었다는 증거일 뿐이다. 그 프로필이 최신이라는 증거, 그 언어의 콘텐츠가 존재한다는 증거, 음성 엔진이 이해 가능하게 들린다는 증거, 독자가 결과를 이해한다는 증거, 과제가 성공한다는 증거가 아니다.

charset은 더 단단한 경계에서 같은 원리가 적용된다. 품질 값은 지원이 실재한 후에야 지원되는 대안들을 순서지을 수 있다. 디코더를 설치할 수 없다. 선택된 페이로드의 레이블이 그 바이트와 일치함을 증명할 수 없다. 게이트웨이가 그 바이트를 보존했거나 렌더링 경로가 모든 문자를 유지했음을 보여줄 수 없다.

따라서 완전한 운용 기록은 승리한 표현식 이상을 필요로 한다. 수신된 특성 집합, 정규화 결과, 평가기 정책, 이용 가능한 후보, 선택된 표현, 런타임 디코더 또는 음성 자원, 렌더 결과, 그리고 서비스가 중요한 경우 사용자의 결과까지 필요하다.

이것들은 중복 로그가 아니다. 서로 다른 질문에 답한다.

레지스트리는 질문을 명명할 수 있다

IANA 미디어 특성 레지스트리는 여전히charset과language를 IETF 트리의 31, 32번 항목으로 나열한다. 이 연속성은 RFC 2987이 내구성 있는 조정 작업을 수행했음을 보여준다. 독립적인 시스템들은 어느 한 응용이 어휘를 소유하지 않은 채 같은 이름과 동등성 의미론을 참조할 수 있었다.

등록은 중앙 평가기를 만들지 않았다. 발신자 또는 기기 프로필은 자신이 선언하는 것을 통제했다. 표현 공급자는 어떤 변형이 존재하는지 통제했다. 수신 구현은 정규화, 매칭, 가중치 부여, 폴백을 통제했다. 사용자는 선택의 효과를 짊어졌다.

이 분업은 Lu Heng의 Minimum Initial Specification과 닮았다. 상호운용에 필요한 최소한의 공유 언어를 표준화하고, 공통 규칙이 필요하지 않은 한 미래의 결정을 국소에 두는 것이다. RFC 2987은 태그 이름, 값 도메인, 비교 의미론을 고정했다. 보편적 순위화 권위를 임명하지는 않았다.

그러나 국소적 자유가 책임을 소멸시키지는 않았다. 하나의 술어를 필수로, 다른 하나를 권고로 취급한 구현이 결정적인 해석을 통제했다. charset 한계를 조용히 완화하면 읽을 수 없는 출력의 위험을 감수했다. 언어 선호를 조용히 경직하면 불필요한 거절의 위험을 감수했다. 그 정책에는 영수증이 필요했다.

Running-Code Primacy가 다음 시험을 제공한다. 표준 등록은 공유 명세이지, 배포된 기기가 자신이 주장하는 디코더, 콘텐츠, 글꼴, 음성, 폴백 경로, 사용자 모델을 갖추었다는 증거가 아니다. 공표는 표현식을 유효하게 만들 수 있다. 무엇이 선택되었고 무엇이 작동했는지는 오직 실행만이 보여준다.

현실의 층위는 분리된 채로 남는다:

  1. 특성 태그와 값이 등록되어 있다.
  2. 표현식이 술어와 가중치를 선언한다.
  3. 별칭과 대소문자가 정규화된다.
  4. 완전한 토큰이 비교된다.
  5. 국소 정책이 대안을 선택한다.
  6. 필요한 디코더 또는 언어 자원이 존재한다.
  7. 표현이 실행되고 제시된다.
  8. 사용자가 그것을 지각하고 이해한다.
  9. 의도된 과제가 성공한다.

앞선 층위가 뒤의 모든 층위를 위해 증언할 권위는 없다.

작은 보안 공시

RFC 2987은 각 태그에 대해 좁은 보안 경고를 담았다. 특정 charset 또는 언어 환경에서 표시 버그가 알려져 있다면, 기기가 그것을 받아들인다는 사실을 드러내는 것이 공격자에게 약간 도움이 될 수 있다는 것이다. 문서는 특정 제품이나 사건을 지목하지 않았고, 역사 분석이 하나를 만들어내서도 안 된다.

그럼에도 경고는 본론을 강화한다. 역량 선언은 운용 데이터다. 선택을 형성하고, 공격 표면을 드러내고, 기대를 만들 수 있다. 더 안전한 시스템은 결정에 필요한 이상을 수집하거나 노출하지 않으며, 광고된 경로가 안전하다는 증명과 공시를 혼동하지 않는다.

RFC 2987의 지속적 기여는 charset과 language를 동등하게 만든 것이 아니다. 두 차이를 지우지 않으면서 공통 메커니즘을 공유하게 한 것이다.

태그는 똑같아 보였다. 비교는 똑같아 보였다. 가중치는 똑같아 보였다.

한 답은 대개 '기계가 이것을 할 수 있거나 할 수 없다'라고 말했다. 다른 답은 대개 '사람은 이쪽을 더 원한다'라고 말했다.

상호운용성은 공통 문법과 이 두 진술의 서로 다른 권위를 모두 보존하는 데 달려 있었다.

출처