요약

  • RFC 3743은 선정된 CJK 문자 이형(變體)을 하나의 행정 패키지로 다루도록 했습니다. 등록자 한 사람이 관련 라벨군 전체를 통제할 수 있으며, 일부만 실제로 존에 활성화되어 있어도 마찬가지였습니다.
  • 언어 이형 테이블(Language Variant Table)이 후보를 생성했고, 선호 이형(preferred variant)은 일반적으로 활성화되며 문자 이형(character variant)은 일반적으로 예약됩니다. 이 RFC는 메커니즘을 제공했을 뿐, 보편적인 언어학적 판단이나 실제 도입 증거를 제시하지는 않았습니다.

DNS 레코드보다 더 큰 도메인 이름

ASCII 조회만으로 보면 도메인 등록은 하나의 문자열에 대한 거래처럼 보입니다. 라벨이 사용 가능하고, 신청자가 이를 등록하고, 존이 이를 게시하는 방식입니다. 국제화된 라벨은 이 그림을 복잡하게 만들었습니다. 중국어·일본어·한국어 표기에서는 서로 다른 코드 포인트가 비슷하게 보이거나, 관련된 의미를 지니거나, 특정 언어·지역에서 이형(variant)으로 취급되는 형태를 나타낼 수 있습니다. DNS 프로토콜은 인코딩된 라벨을 비교할 수 있습니다. 하지만 어떤 유니코드 형태 둘이 같은 등록자에게 속해야 하는지를 프로토콜 스스로 판단할 수는 없습니다.

바로 이 공백이 2004년 4월 Informational 문서로 발행된RFC 3743에서 공동 엔지니어링 팀(Joint Engineering Team, JET)이 다룬 문제였습니다. 기여자들은 중국 본토, 대만, 한국, 일본의 네트워크 정보 커뮤니티 등에서 나왔습니다. IESG 노트는 정책과 집행 메커니즘을 연결하려는 노력을 높이 평가하면서도, IETF가 존의 정책을 강제하는 것은 아니라는 점을 똑같이 명확히 했습니다. 동일한 테이블 형식이 서로 다른 현지 선택을 지원할 수 있었습니다.

이것은 유니코드 라벨을 DNS에서 사용하는 ASCII 호환 형태로 변환하는 문제와는 다릅니다. 앞선 IDNA 문서들이 준비(preparation)와 인코딩을 표준화했다면, RFC 3743은 존이 라벨을 수용한 뒤 혼동 가능성이 있는 이형을 어떻게 행정적으로 다룰지를 다루었습니다. 프로토콜은 문자열이 기술적 프로파일을 통과하는지 응용 프로그램에 알려줄 수 있습니다. 하지만 모든 언어 공동체가 보는 동등성 판단을 대신 정해줄 수는 없습니다.

테이블이 언어 정책을 등록 워크플로로 바꾸는 방식

이 메커니즘은 존이 지원하는 각 언어에 대한 언어 이형 테이블(LVT)에서 시작합니다. 허용된 각 코드 포인트에 대해 테이블은 유효 코드 포인트, 가능한 선호 이형, 문자 이형을 식별합니다. '선호(preferred)'와 '문자(character)'라는 표기는 문자 체계의 보편적 서열이 아니라 서로 다른 행정적 처리 방식을 설명하며, 생성된 모든 문자열이 실제 의미 있는 단어라는 주장도 아닙니다.

등록 시 제안된 라벨은 먼저 IDNA 시대의 Nameprep 규칙에 따라 처리됩니다. 레지스트리는 요청에 연관된 모든 언어의 유효 코드 포인트 테이블과 이를 대조합니다. 그 다음 선호 이형과 문자 이형의 조합을 생성하고 중복을 제거한 뒤, 후보를 기존 등록 및 예약과 대조합니다. 존 고유의 필터링으로 테이블이 원래 생성했을 형태를 제외할 수도 있습니다. 이는 유니코드의 자동적 결과가 아니라, 테이블과 현지 절차가 정책 입력을 공급하는 구조입니다.

활성화와 예약의 구분이 핵심입니다. 원래 라벨과 자격을 갖춘 선호 이형은 일반적으로 존 파일에서 활성화되는 Zone Variant 집합을 이룹니다. 문자 이형은 보통 예약 상태로 두어 다른 신청자가 등록할 수 없지만, 반드시 활성 라벨로 게시되는 것은 아닙니다. RFC 3743은 원래 라벨, 연관 언어 집합, 활성화된 존 이형, 예약된 이형을 묶어 “IDL Package”라고 부릅니다.

이 패키지는 행정의 단위를 바꿉니다. 전통적 도메인 절차는 한 번에 라벨 하나를 등록·삭제·이전합니다. 이 모델에서는 패키지가 원자적(atom)입니다. 등록된 라벨의 이전이나 삭제는 연관된 이형 전체에 영향을 줍니다. 이 규칙은 존이 관련 형태로 취급하기로 결정한 문자열들을 두 명의 보유자가 나눠 가져가는 일을 막습니다. 동시에 등록자의 거래에 실제 활성 DNS 이름으로 나타나지 않는 라벨까지 포함될 수 있음을 의미합니다.

RFC의 실습 예제는 언어 연관이 왜 중요한지 보여 줍니다. 하나의 라벨이 여러 언어 테이블에서 수용 가능할 수 있고, 테이블마다 서로 다른 선호 형태를 산출할 수 있으며, 어떤 선택된 언어에서는 코드 포인트가 유효하지 않아 실패할 수도 있습니다. 이 예제들은 알고리즘 설명일 뿐, 특정 레지스트리가 특정 테이블을 채택했다거나 어떤 상업 도메인이 실제로 패키지 모델로 등록되었다는 증거가 아닙니다.

패키지가 증명할 수 없는 것

RFC 3743은 중요한 선택들을 의도적으로 메커니즘 밖에 남겨 둡니다. 각 존이 자신의 테이블, 언어 연관, 충돌 정책, 생성할 이형 수의 상한, 등록기관과 레지스트리 간의 역할 분담을 결정합니다. RFC는 예제에서 선착순을 가정하지만, 존이 자체 권리·분쟁 규칙으로 대체할 수 있도록 허용합니다. 어떤 문자열에 법적 권리가 있는지 특정하지 않고, 패키지가 활성화되었다는 증명, A-label이 존에 삽입되었다는 표시, 쿼리가 응답한다는 실증도 제공하지 않습니다.

이후의 IDNA2008 문서들은 유용한 경계선을 제공합니다. 이 문서들은 기술적 유효성과 등록·조회 동작을 규정하면서, 레지스트리가 현지 제한을 추가할 수 있음을 인정합니다. 그러한 연속성이 RFC 3743의 IDNA2003 시대 알고리즘을 현재의 프로토콜 규칙으로 만들지는 않습니다. 이후 프로토콜이 소급하여 JET 테이블을 보편적 언어 표준으로 만들지도 않습니다. 유효성 검사, 레지스트리 정책, 등록, 존 게시, 성공적 응답은 여전히 서로 다른 영수증입니다.

따라서 역사적 기여는 행정 아키텍처입니다. JET는 모든 CJK 동등성 판단을 DNS에 인코딩하려 하지 않았습니다. 대신 존 운영자에게 현지 이형 선택을 표현하고 관련 라벨들을 한 패키지 소유자에게 묶는 방법을 제공했습니다. 이는 분할 등록 위험의 한 유형을 줄였지만, 새로운 의존성을 도입했습니다. 존의 언어 테이블과 수명 주기 규칙이 신청자가 실제로 받는 것의 일부가 된 것입니다. 보이는 도메인은 라벨 하나일 수 있지만, 예약된 대상은 훨씬 클 수 있습니다.

출처