요약

  • RFC 3987은 읽을 수 있거나 인코딩되거나 정규화된 모든 형태를 서로 교환 가능하다고 선언하지 않으면서도, 인터넷 식별자를 유니코드로 읽을 수 있게 만들었다.
  • 이 RFC는 운영자에게 원본 문자열, 전송 바이트, URI 매핑, 로컬 비교, 도달한 자원을 분리하도록 요구했다.

2005년 1월,RFC 3987은 국제화된 자원 식별자(Internationalized Resource Identifier)를 도입했다. 이 RFC의상태 기록,정오표 기록,Datatracker 이력은 의도적으로 제한된 조치를 보존하고 있다. 이 RFC는 URI를 재정의하지 않았다. 대신 보완적인 프로토콜 요소—유니코드 문자 시퀀스—를 만들고, 그 시퀀스를 URI로 매핑하는 결정론적 방법을 정의했다.

이 선택이 중요한 이유는 가독성과 식별이 같은 작업이 아니기 때문이다. 사용자는 아랍어, 일본어 또는 악센트가 있는 라틴 문자로 주소를 입력할 수 있다. 레거시 프로토콜은 퍼센트 인코딩된 URI를 전달할 수 있다. 캐시는 정규화된 형태를 비교할 수 있다. DNS 구현은 하나의 호스트 레이블을 변환할 수 있다. 그 후 애플리케이션이 자원을 검색한다. 이 단계들은 조율된 과정일 수 있지만, 어느 하나도 다른 단계를 대신할 영수증이 아니다.

RFC 3986과 그상태,정오표,이력은 이미 URI 비교를 목적 의존적으로 만들어 놓았다. RFC 3987은 그 사다리를 물려받아 문자 대 옥텟 문제를 추가했다. UTF-8과 UTF-16으로 저장된 두 문자열은 같은 문자 시퀀스를 나타내면서도 바이트 비교에서는 일치하지 않을 수 있다. 따라서 단순한 IRI 비교는 두 문자열을 공통 인코딩 형태로 맞춘 뒤 코드 포인트 단위로 수행된다.

이 RFC는 이어서 가장 날카로운 경계를 긋는다. 그 문자 비교는 먼저 IRI를 URI로 매핑해서는 안 된다. 매핑은 추가적이고 가짜인 동등성을 만들어 낼 수 있다. 전송에 유용한 변환이 자동으로 항등 함수처럼 안전하지는 않다. 이 RFC는 이 규칙을 운영상 결과까지 밀어붙인다. 식별자로 사용될 수 있는 IRI는 전송 중에 수정되어서는 안 된다.

정규화는 사라지지 않는다. 이름이 붙은 장소로 옮겨 간다. 종이 문서나 알려진 비유니코드 인코딩에서 만들어진 IRI는 IRI-to-URI 변환 과정에서 NFC로 준비된다. 이미 UTF-8이나 UTF-16으로 전달되는 IRI는 이 단계에서 정규화되지 않는다. 작성자에게는 IRI를 NFC로 만들도록 권고하지만, 제3자에게는 시퀀스의 소유자가 어떻게 처리하는지 알 수 없을 때 기존 식별자를 임의로 정규화하지 말라고 경고한다.

이후RFC 5198과 그상태,정오표,Datatracker 기록은 NFC가 네트워크 텍스트 비교를 왜 더 쉽게 만들고, 할당된 정규화 문자열이 왜 안정성을 위해 설계되었는지를 설명했다. 그 네트워크 텍스트 규범은 생성과 교환을 지원한다. 그러나 RFC 3987의 식별자 보관 규칙을 취소하지는 않는다. 정준 텍스트 형태라도 중개자가 받은 증거를 대체할 수 있는 허가는 아니다.

퍼센트 인코딩은 유용한 시험대를 제공한다. 애플리케이션이 특정 로컬 동등성을 필요로 할 때는 서로 다른 16진 대소문자나 인코딩된 비예약 문자를 맞출 수 있다. RFC 3987은 그 비교를 위한 변환과 이스케이프 정렬을 허용한 뒤, 식별자가 다시 전달되거나 재사용될 경우 원본 형태를 보존할 것을 요구한다. 정규화된 비교 키는 색인이지 원본 기록이 아니다.

또한 문자열 비교만으로 세계 전체를 알 수 없다. 두 개의 동등한 문자열은 선택된 규칙 아래 동등함을 보일 수 있다. 하지만 두 개의 서로 다른 문자열이 서로 다른 자원을 명명한다고 그로부터 증명되지는 않는다. 하나의 소유자가 여러 식별자로 같은 객체를 제공할 수도 있기 때문이다. 검색 역시 일반적인 경우 비교 문제를 해결하지 못한다. 비교자는 양쪽 자원에 대한 완전한 지식이나 통제권을 거의 갖지 못하기 때문이다.

도메인 이름은 또 하나의 경계를 더한다. RFC 3987은 이전의 IDNA 모델을 전제로 작성되었다. 이후RFC 5890, 그상태,정오표,이력은 유니코드 U-label과 ASCII A-label, 등록과 조회를 구분했다.RFC 5891, 그상태,정오표,Datatracker 이력은 검증 프로토콜을 정의한다. 따라서 읽을 수 있는 호스트 레이블은 아직 등록된 레이블도, 성공한 조회도, 승인된 자원도 아니다.

RFC 5895, 그상태,정오표,이력은 입력 경계를 명시적으로 만들었다. 로캘을 고려한 매핑은 도메인 이름 프로토콜 처리 이전의 사용자 인터페이스에 속한다. 이는 보편적인 전송 알고리즘이 아니다. 터키어 대소문자, 아시아 폭 형태, 타이핑, 음성 입력, 복사·붙여넣기는 서로 다른 사용자 대면 결정을 요구할 수 있다.

따라서 RFC 3987의 역사적 성과는 단일한 마법의 변환이 아니었다. 그것은 보관(custody)의 아키텍처였다. 원본 문자를 유지한다. 인코딩을 기록한다. 매핑에 이름을 붙인다. 비교 목적을 명시한다. 스킴과 도메인 규칙을 각자의 경계에서 적용한다. 리졸루션과 애플리케이션 결과는 나중에 기록한다. 식별자는 더 많은 인간 언어가 시스템에 들어올 수 있게 되면서 읽을 수 있게 되었으며, 시스템이 모든 표현을 문서화되지 않은 하나의 문자열로 압축하는 일을 거부할 때만 신뢰성을 유지했다.

출처