요약

  • RFC 3536은 프로토콜이 운반하는 인코딩된 옥텟을 추상 문자, 문자 체계(스크립트), 언어, 그리고 렌더러가 선택한 글리프와 분리했다. 이 어떤 계층도 다음 계층의 자동적 증명이 될 수 없다.
  • 2003년 용어집은 의도적으로 Informational이자 비규범적이었으며, 2011년 RFC 6365가 이를 폐기(obsolete)했다. 그 지속 가능한 교훈은 증거론적이다. 그럴듯한 표시는 렌더링 수령 증명서일 뿐, 언어나 의미의 증거가 아니다.

지원 엔지니어가 화면에서 고객 이름을 살펴본다고 하자. 글자는 익숙하고, 균일하게 배치되어 있으며, 완벽하게 판독 가능하다. 엔지니어는 텍스트 파이프라인이 정상이라고 표시한다. 그러나 같은 그림은 잘못된 문자셋 레이블, 의도하지 않은 정규화, 폰트 폴백, 재배열된 양방향 실행, 혹은 소프트웨어가 내린 언어 추정 이후에도 만들어졌을 수 있다. 화면은 사실 하나를 제공했을 뿐이다. 렌더러가 그릴 모양을 찾았다는 것. 화면은 텍스트의 보관 이력을 재구성하지 못했다.

RFC 3536은 2003년 5월IETF의 국제화에 사용되는 용어(Terminology Used in Internationalization in the IETF)라는 제목으로 발표되었다. 이는 문자 인코딩도 상호운용성 프로파일도 아니었다. 엔지니어들이 서로 다른 계층에 같은 단어를 사용하고 있었기 때문에 만들어진 Informational 용어집이었다. 저자들은 한계에 대해 이례적으로 솔직했다. 정의는 규범적이지 않았고, 목록은 완전하지 않았으며, 커뮤니티는 모든 용어에 대해—특히 “언어”에 대해—합의하지 못했다. RFC 편집기의 고정된 오류 기록에는 오류가 없지만, 비어 있는 오류 목록이 잠정적 어휘를 확정된 존재론으로 바꾸어 주지는 않는다.

용어집은 네트워크 프로토콜이 시작하는 곳에서 시작한다. 인코딩된 데이터다. 비트는 옥텟으로 묶이고, 문자셋은 수신자에게 옥텟이 추상 문자와 어떻게 대응하는지 알려준다. RFC 3536은 이 배열을 코드화된 문자 집합과 문자 인코딩 방식의 결합으로 기술하고 IANA 등록 이름을 가리킨다. RFC 3629에서 인터넷 사용을 위해 표준화된 UTF-8도 그런 인코딩 방식 중 하나다. 따라서 문자셋 레이블은 디코딩 질문에 답한다. 디코딩된 문장이 프랑스어인지, 아랍어인지, 일본어인지, 잘 쓰인 문장인지, 무슨 의미인지는 말하지 않는다.

다음 경계는 화면이 그것을 감추기 때문에 놓치기 쉽다. 문자(character)는 고정된 모습이 아니라 이름과 속성으로 식별되는 추상 데이터 요소다. 글리프(glyph)는 렌더링된 형태다. 렌더러는 폰트, 셰이핑 규칙과 문맥을 사용해 글리프를 선택한다. 하나의 문자는 여러 글리프를 가질 수 있고, 여러 문자 열이 관찰자가 동일하다고 판단하는 형태를 만들 수 있으며, 하나의 눈에 보이는 형태는 언어적 문맥 없이는 모호할 수 있다. “제대로 보인다”는 것은 출력에 대한 관찰이지 입력에 대한 역방향 증명이 아니다.

스크립트와 언어도 서로 겹쳐지지 않는다. 스크립트는 언어의 기록 형식에 사용되는 그래픽 문자들의 집합이다. 하나의 스크립트가 여러 언어에 쓰일 수 있고, 하나의 언어는 둘 이상의 스크립트로 쓰일 수 있다. 스크립트 실행 구간을 인식하면 일부 렌더링 선택을 좁히지만 언어를 식별하지는 않는다. RFC 3066에서 발전해 이후 RFC 5646이 포괄적으로 규정한 언어 태그는 별도의 선언을 전달한다. 구문상 유효한 태그조차 제공된 메타데이터일 뿐이며, 해당 구절이 유창하거나 올바르게 분류되었거나 이해되었다는 증거가 아니다.

RFC 2277은 이미 이 기계 장치의 인간적 목적을 표현한 바 있다. 프로토콜 자체에는 자연 언어가 없지만, 그것을 통과하는 텍스트 문자열은 사람들이 사용한다. 이것이 중요한 이유는, “국제화되었다”는 구문 분석기가 비(非)ASCII 바이트를 수용했다는 의미만으로는 성립할 수 없기 때문이다. 이 사슬은 입력, 저장, 비교, 검색, 정렬, 렌더링, 음성 또는 촉각 출력, 그리고 마지막으로 결과를 바탕으로 행동할 수 있는 사람의 능력까지 이어진다.

정규화는 외형이 특히 약한 지름길인 이유를 드러낸다. 유니코드는 정준적으로 동등한 텍스트를 서로 다른 코드 포인트 열로 표현할 수 있다. 유니코드 표준 부록 #15는 정규화 형식을 정의하고, RFC 5198은 이후 네트워크 교환을 위한 준비 프로파일을 규정한다. RFC 3536의 결정적 절차적 요점은 프로토콜이 정규화가 어디에서 일어나는지 명시해야 한다는 것이다. 한 시스템이 입력 시에 조용히 정규화하고, 다른 시스템이 비교 시에, 또 다른 시스템이 전혀 하지 않는다면, 동일하게 보이는 문자열들이 서로 다른 키로 동작할 수 있다. 혹은 감사 가능한 결정 없이 서로 다른 레코드가 병합될 수 있다.

그 주제는 기존 RFC 5137의 경계 앞에서 멈춘다. 여기서 질문은 유니코드 이스케이프가 정규화된 식별자가 되었는지, 두 계정 핸들이 충돌하는지가 아니다. 문제는 더 넓은 표현 사슬이다. 수신된 옥텟이 렌더러가 글리프를 선택하기 전에 어떻게 문자 정체성, 스크립트, 언어 문맥을 얻는가. 식별자 정책은 그 사슬의 하나의 적용 사례일 뿐이며, 이 역사의 주제가 아니다.

순서화는 또 하나의 시험을 제공한다. 콜레이션(collation)은 코드 포인트 수치로 정렬하는 것과 같지 않다. 인간 독자는 언어와 관습에 의해 형성되는 순서를 기대하며, 같은 스크립트를 쓰는 두 커뮤니티가 같은 문자열을 다르게 배치할 수 있다. 데이터베이스는 완벽하게 결정론적인 코드 포인트 순서를 반환하면서도 독자에게는 잘못된 색인을 전달할 수 있다. “정렬 완료”라는 수령 증명은 선택된 콜레이션이 선언된 언어에 부합했는지에 대해 아무것도 말하지 않는다.

양방향 텍스트는 공간적 함정을 더한다. 메모리 순서와 표시 순서는 다를 수 있다. 스크린샷은 근본적인 열을 신뢰할 수 있게 드러내지 못하며, 커서 이동, 복사, 음성 출력은 정적인 그림이 감춘 순서를 노출할 수 있다. 렌더링은 픽셀에 국한되지도 않는다. RFC 3536은 청각적, 촉각적 형태까지 포함한다. 그럴듯해 보이는 시각적 글리프가 고장난 음성 합성이나 사용할 수 없는 점자 출력과 공존할 수 있다.

역사적 지위는 정확해야 한다. RFC 3536은 결코 인터넷 표준이 아니었다. 2011년 9월, IETF 합의와 공개 검토를 거쳐 RFC 6365가 BCP 166으로 발표되며 RFC 3536을 명시적으로 폐기했다. 이후 RFC 7997은 RFC 문서 자체의 비ASCII 문자 규칙을 변경했다. 이 발전들은 어휘가 더 운용적이 되고, 발행 관행이 더 포용적이 되었음을 보여준다. 그것이 2003년의 모든 정의를 소급해 규범적으로 만들지는 않는다.

RFC 3536의 보안 절은 보안이 논의되지 않았다고 말한다. 그 문장은 그대로 유지되어야 한다. 현대의 운영자들은 인코딩, 방향성, 혼동 가능한 표시가 위험에 영향을 준다는 것을 관찰할 수 있지만, 이 용어집에 성숙한 위협 모델을 돌려서는 안 된다. 절제된 역사적 주장은 더 좁다. 시스템은 인코딩된 데이터, 추상 텍스트, 언어적 문맥, 렌더링 결과 사이의 경계를 지울 때 감사하기 어려워진다.

따라서 완전한 증거 사슬은 스크린샷보다 길다. 수신된 옥텟과 문자셋 레이블을 보존하고, 이를 디코딩하고, 문자 열을 검증하고, 기록된 단계에서 이름 붙은 정규화 정책을 적용하고, 언어 태그와 그 출처를 보존하고, 스크립트와 양방향 실행을 식별하고, 알려진 엔진과 폰트로 셰이핑하고, 폴백을 기록하고, 의도된 시각·청각·촉각 채널로 렌더링하고, 선택된 콜레이션을 적용하고, 의도된 독자가 결과를 이해했는지 시험한다. 눈부신 글리프는 사슬의 단 하나 고리만 닫는다.

출처