요약

  • RFC 3490은 DNS를 ASCII로 유지하고 IDNA를 애플리케이션 내부에 삽입했다.ToASCII는 레이블을 거부할 수 있었지만,ToUnicode는 의도적으로 절대 실패하지 않고 디코딩이나 왕복 검증이 실패하면 원래 입력을 그대로 반환했다.
  • 따라서 반환된 표시 문자열은 유효한 레이블, 레지스트리 접수, 존 삽입, 응답 확인, DNSSEC 인증 또는 통제권의 증거가 아니었다. 각각은 서로 다른 계층에 속했고 각자 자신의 영수증이 필요했다.

RFC 3490에서 가장 계몽적인 문장은 새로운 알파벳에 관한 것이 아니라 실패에 관한 것이었다. “ToUnicode never fails.” 즉 ToUnicode는 절대 실패하지 않는다는 것이다. 대충 읽으면 만인의 이해를 보장한다는 약속처럼 들린다. 그러나 알고리즘으로 읽으면 훨씬 좁은 의미다. 변환 단계가 실패하면 그 연산은 원래 입력을 즉시 반환했다. 애플리케이션은 여전히 화면에 보여줄 무언가를 갖고 있었지만, 그렇다고 해서 유효한 국제화 도메인 이름을 갖게 되는 것은 아니었다.

이러한 동작이 합리적이었던 이유는 2003년 설계가 DNS의 개조가 아니라 가교였기 때문이다. RFC 3490은 DNS 패킷에 유니코드를 추가하지도, 새로운 네임 서버를 요구하지도 않았다. 대신 애플리케이션 안에 심(shim)을 넣었다. 사람 쪽에서 애플리케이션은 유니코드를 받아들이고 표시할 수 있었다. 인프라 쪽에서는 기존 리졸버 인터페이스, 존 파일, DNS 서버가 계속 ASCII 레이블을 전달했다. 국제화는 이 접합부에서 일어났다.

표준은 이 접합부가 중요해지는 지점을 “도메인 이름 슬롯”이라고 명명했다. DNS QNAME, 리졸버 함수 인자, 메일 헤더에서 @ 뒤에 오는 도메인, URI 필드의 호스트 부분이 그것이다. 이름을 언급하는 산문이 자동으로 슬롯이 되지는 않았다. 이는 이미 범위의 규율이었다. 문자열의 의미는 모양이 아니라 어디에서 사용되는지에 달려 있었다.

DNS를 향한 경로는 엄격했다.ToASCII는 한 번에 하나의 레이블을 처리했다. 비 ASCII 입력에 대해서는 Nameprep을 호출하고, 이전의 문자-숫자-하이픈 규칙을 강제할 수 있으며, 이미 예약된 접두어로 시작하는 비 ASCII 시퀀스는 거부하고, Punycode로 인코딩하고,xn--를 붙이고, 최종 길이가 1~63 코드 포인트 사이여야 했다. 어느 단계든 실패하면 전체가 실패였다. 하나의 레이블이라도 실패하면 그 도메인 이름은 IDN으로 사용해서는 안 된다고 RFC 3490은 명시했다.

사람을 향한 반환 경로는 다른 역할을 맡았다.ToUnicode는 먼저 ACE 접두어를 인식하고 제거하고, 나머지를 디코딩한 뒤, 그 결과를 다시ToASCII에 통과시켰다. 새로 생성된 ASCII 레이블이 저장된 입력과 ASCII 대소문자를 구분 없이 일치할 때에만 디코딩된 유니코드 형태를 노출했다. 이 왕복 검증은 임의의 접두어 형태 문자열이 Punycode가 몇 글자를 생성했다는 이유만으로 권위를 얻는 것을 막았다.

그러나 표시 소프트웨어가 검증 실패 시 그냥 사라질 수는 없었다. 그래서ToUnicode는 원래 레이블을 반환했다. RFC 3490은 운영상의 단서를 덧붙였다.ToUnicode이후에도 레이블이 여전히 ACE 접두어로 시작한다면, 그것은 유효한 ACE 레이블이 아니며 중간 유니코드 문자열과 동등하지 않다. “반환됨”은 표시 경로에 안전한 대체 동작이 있었다는 뜻이지 “수용됨”이라는 뜻이 아니었다.

이것은 현대 인터페이스가 흔히 평탄화해버리는 증거의 사다리를 만든다. 문자열은 표시 가능할 수 있다.ToASCII를 통과할 수 있다. 레지스트리는 더 엄격한 언어·문자 정책에 따라 이를 수용할 수 있다. A-label은 존에 삽입될 수 있다. 리졸버는 응답을 받을 수 있다. DNSSEC은 그 응답을 인증할 수 있다. 사용자는 표시된 이름이 의도된 당사자임을 인식할 수 있다. 이 어느 사실도 다음 사실을 자동으로 제공하지 않는다.

RFC 3490은 가장 날카로운 경계 중 하나를 명시했다. DNSSEC은 DNS에 저장되고 서명된 ASCII 도메인 이름을 인증하며, 유니코드 형태도, 두 형태 사이의 매핑도 인증하지 않는다. 암호학적으로 유효한 DNS 응답조차 사람이 표시된 표기를 어떤 의미로 믿었는지 보증하지 못했다. 정확한 프로토콜 신원과 지각된 신원은 서로 다른 계층에 있었다.

표준은 더 넓은 언어학적 약속도 거부했다. 유니코드는 문자 범위를 넓혔지만 DNS는 정확 일치 서비스로 남았다. 비슷하게 보이는 코드 포인트, 대체 표기, 한자의 정체와 간체, 언어별 등가 관계는 모두 병합되지 않았다. 레지스트리는 추가 규칙을 둘 수 있었다. 변환은 상호운용성의 메커니즘이었지, 이름에 관한 보편적 이론이 아니었다.

이후의 IDNA2008 작업은 이 구분을 더 날카롭게 했다. RFC 5890과 RFC 5891은 RFC 3490의 어휘를 A-label과 U-label로 대체하고 등록과 조회를 별도의 프로토콜로 서술했다. 등록은 제출된 두 형태의 정확한 일치를 요구하고 불일치를 거부할 수 있었다. 조회는 더 관대했지만 여전히 검증 규칙을 두었다. RFC 5891은 그 원칙을 실용적으로 단언했다. 비교의 성공이 유효성을 함축하지는 않는다.

RFC 5895는 사용자 인터페이스 매핑을 공유 프로토콜 이전의 로컬 처리로 옮겼다. 이 변화는 Lu Heng의 최소 초기 명세 원칙과 공명한다. 공통 메커니즘은 상호운용성에 필요한 것만 운반해야 하며, 언어 민감적 입력, 표현, 정책 결정은 이를 판단할 수 있는 사람과 기관 가까이에 남아야 한다. DNS 코어는 전 세계적으로 사용 가능한 식별자를 운반하기 위해 전 지구적 언어 권위가 될 필요가 없다.

따라서 RFC 3490의 역사적 성과는 모든 이름이 읽을 수 있게 되었다는 것이 아니었다. 기존 인프라를 보존하면서 두 표현 사이의 경계를 표시했다는 것이다. 나중에 대체된 메커니즘보다 그 조용한 경고가 오래 남았다. 항상 무언가를 반환하는 함수는 연속성에는 훌륭하지만 유효성의 판정자로는 끔찍할 수 있다. 읽을 수 있는 텍스트는 표시의 증거다. 수용에는 또 다른 영수증이 필요하다.

출처