RFC 3490-애플리케이션에서 도메인 이름 국제화 (IDNA)

RFC 3490-애플리케이션에서 도메인 이름 국제화 (IDNA)

인터넷 RFC 색인

유즈넷 FAQ 색인

기타 FAQ

서류

도구

검색

FAQ 검색

RFC 검색

IFC 홈

도시

국가

병원

웹 호스팅 등급

[ RFC 색인 | 유즈넷 FAQ | 웹 FAQ | 문서 | 도시 | SEC 서류 | 학교 ]

네트워크 워킹 그룹 P. Faltstrom 의견 요청 : 3490 Cisco 카테고리 : Standards Track P. Hoffman IMC 및 VPNC A. Costello UC 버클리 2003 년 3 월 응용 프로그램에서 도메인 이름 국제화 (IDNA) 이 메모의 상태 이 문서는 인터넷 표준 추적 프로토콜을 지정합니다.

인터넷 커뮤니티, 토론 및 제안 요청 개량. "인터넷"의 최신판을 참조하십시오. 표준화 상태에 대한 공식 프로토콜 표준 "(STD 1) 및이 프로토콜의 상태. 이 메모의 배포는 무제한입니다.

저작권 고지 Copyright (C) The Internet Society (2003). 판권 소유. 요약 지금까지는 도메인 이름을 사용하는 표준 방법이 없었습니다. ASCII 레퍼토리 외부의 문자. 이 문서는 국제화 도메인 이름 (IDN) 및 처리를위한 IDNA (Internationalizing Domain Names in Applications) 표준 방식으로. IDN은 큰 문자를 사용합니다.

레퍼토리 (유니 코드),하지만 IDNA는 비 ASCII 문자를 이미 허용 된 ASCII 문자 만 사용하여 표시됩니다. 오늘은 호스트 이름이라고합니다. 이 이전 버전과 호환되는 표현은 DNS와 같은 기존 프로토콜에 필요하므로 IDN이 기존 인프라에 대한 변경없이 도입되었습니다.

IDNA는 자유 텍스트가 아닌 도메인 이름 처리만을 의미합니다. ​

목차 1. 소개............................................... ... 2 1.1 문제 설명 ......................................... 3 1.2 IDNA의 한계 ....................................... 3 1.3 애플리케이션 개발자를위한 간략한 개요 ................. 4 2. 용어 ............................................... .... 5 3. 요구 사항 및 적용 가능성 ................................ 7 3.1 요구 사항 .............................................. 7 3.2 적용 성 ............................................. 8 3.2.1. DNS 리소스 레코드 ................................ 8 3.2.2. 도메인 이름에 저장된 비 도메인 이름 데이터 유형 ... 9 4. 변환 작업 ......................................... 9 4.1 ToASCII ................................................ ... 10 4.2 ToUnicode ................................................ . 11 5. ACE 접두사 .............................................. ...... 12 6. DNS를 사용하는 일반적인 애플리케이션에 대한 시사점 ..................... 13 6.1 애플리케이션의 입력 및 표시 ......................... 14 6.2 애플리케이션 및 리졸버 라이브러리 ....................... 15 6.3 DNS 서버 ............................................... 15 6.4 원시 ACE 인코딩에 사용자 노출 방지 ........... 16 6.5 IDN 도메인 이름의 DNSSEC 인증 ................. 16 7. 네임 서버 고려 사항 .................................... 17 8. 루트 서버 고려 사항 .................................... 17 9. 참고 문헌 ............................................... ..... 18 9.1 참고 문헌 ...................................... 18 9.2 참고 자료 .................................... 18 10. 보안 고려 사항 ...................................... 19 11. IANA 고려 사항 .......................................... 20 12. 저자 주소 ........................................... 21 13. 전체 저작권 성명 ..................................... 22 1. 소개/

IDNA는 응용 프로그램이 특정 ASCII 이름 레이블을 사용하도록 허용하여 작동합니다. (특수 접두사로 시작) 비 ASCII 이름 레이블을 나타냅니다.​

하위 계층 프로토콜은이를 인식 할 필요가 없습니다. 따라서 IDNA는 인프라 변경에 의존하지 않습니다.

특히 IDNA DNS 서버, 확인자 또는 프로토콜의 변경 사항에 의존하지 않습니다.

요소, 기존 DNS에서 제공하는 ASCII 이름 서비스 IDNA에는 전적으로 충분합니다.

이 문서는 IDNA를 준수하기위한 애플리케이션을 요구하지 않습니다. 그러나 응용 프로그램은 IDN을 지원하기 위해 IDNA를 사용할 수 있습니다. 기존 인프라와의 상호 운용성을 유지합니다. 만약 응용 프로그램이 도메인 이름, IDNA에 비 ASCII 문자를 사용하려고합니다. 현재 정의 된 유일한 옵션입니다. IDNA 지원 추가 기존 응용 프로그램은 응용 프로그램 만 변경해야합니다.

사용자 인터페이스에 유연성을위한 여지를 남깁니다. IDN 솔루션에 대한 많은 논의는 전환 문제와 IDN이 모든 구성 요소가 업데이트되었습니다. 선택하지 않은 제안 IDN 워킹 그룹은 사용자 애플리케이션, 리졸버, 사용자가 사용하기 위해 업데이트되는 DNS 서버 국제화 된 도메인 이름. 널리 퍼진 것에 의존하기보다는 모든 구성 요소의 업데이트, IDNA는 사용자 업데이트에 따라 다릅니다.,​

응용 프로그램 만; DNS 프로토콜이나 기타 사항을 변경할 필요가 없습니다. 사용자 컴퓨터의 DNS 서버 또는 확인자. 1.1 문제 설명 IDNA 사양은 레퍼토리 확장 문제를 해결합니다.

유니 코드를 포함하기 위해 도메인 이름에 사용할 수있는 문자 수 레퍼토리 (일부 제한 있음). IDNA는 DNS가 제공하는 서비스를 애플리케이션으로 확장하지 않습니다. 대신 응용 프로그램 (함축적으로 사용자)이 계속됩니다. 정확히 일치하는 조회 서비스를 확인합니다. 하나의 정확히 일치하는 이름이거나 일치하는 이름이 없습니다. ​

이 모델은 기존 응용 프로그램이 잘 작동하지만 필요 여부에 관계없이 사용자가 정확한 철자를 알고있는 국제화 된 도메인 이름 사용자가 웹과 같은 애플리케이션에 입력하는 도메인 이름 브라우저 및 메일 사용자 에이전트. 더 큰 소개 문자 레퍼토리는 잠재적으로 맞춤법 오류를 만듭니다. 특히 경우에 따라 동일한 모양을 제공하므로 명함의 예, 여러 유니 코드 코드와 시각적으로 일치 할 수 있음 포인트 또는 코드 포인트의 여러 시퀀스. IDNA를 사용하면 다음을 방지 할뿐만 아니라 기존 인프라 (예 : DNS 서버 및 메일 전송 에이전트), 또한 IDN의 기본적인 사용을 허용함으로써 비 ASCII의 ASCII 표현을 사용하여 애플리케이션에서 이름 레이블. 이러한 이름은 읽기에 매우 사용자 친화적이지 않지만 유형이므로 사용자 입력에 적합하지 않습니다.​

예) 이메일에 답장하고 URL을 클릭해도 표시된 도메인 이름은 사용자가 이해할 수 없습니다. 하기 위해 사용자 친화적 인 IDN 입력 및 출력, 애플리케이션 허용 이 사양에 맞게 수정해야합니다. IDNA는 유니 코드 문자 레퍼토리를 사용하므로 다른 사람을 기다리는 데 내재 된 상당한 지연 특정 문자 집합은 다른 사람에 의해 IDN 목적으로 정의됩니다. ​

표준 개발 조직. 1.2 IDNA의 한계 IDNA 프로토콜은 사용자의 모든 언어 문제를 해결하지 않습니다. 다른 스크립트에 이름을 입력합니다. 많은 중요한 언어 기반 스크립트 기반 매핑은 IDNA에서 다루지 않으며 프로토콜 외부에서 처리됩니다.

예를 들어, 입력 된 이름 중국어 번체 및 간체 문자의 혼합은 단일 정식 이름에 매핑됩니다. 또 다른 예는 스칸디나비아입니다. U + 00F6 (LATIN SMALL LETTER O WITH DIAERESIS)는 U + 00F8 (LATIN SMALL LETTER O WITH 뇌졸중). 자세히 고려되지 않은 중요한 문제의 예 IDNA는 진입하는 사용자에게 높은 확률을 제공하는 방법입니다.

시각적 정보를 기반으로 한 도메인 이름 (예 : 비즈니스 카드 또는 광고판) 또는 청각 정보 (예 : 전화 또는 라디오)가 IDN을 올바르게 입력합니다. ASCII에도 유사한 문제가 있습니다. 예를 들어 도메인 이름 간의 시각적 혼동 가능성 문자 'O'와 숫자 0, 그러나 더 큰 도입 캐릭터 레퍼토리는 비슷한 기회를 더 많이 만듭니다. 비슷하게 들리는 이름. 이것은 복잡한 언어, 컴퓨터의 입력 방법 등과 관련된 문제. 또한, 높은 수준에 필요한 매칭 및 검색의 종류 성공 확률은 DNS의 역할과 정확히 일치하는 기능. ​

애플리케이션 개발자를위한 간략한 개요 응용 프로그램은 IDNA를 사용하여 국제화 된 도메인 이름을 지원할 수 있습니다.

DNS를 포함하여 ASCII 도메인 이름이 이미 지원되는 모든 곳 마스터 파일 및 리졸버 인터페이스. (응용 프로그램은 또한 비 ASCII를 사용하여 직접 IDN을 지원하는 프로토콜 및 인터페이스 표현. IDNA는 특정 사항을 처방하지 않습니다. ​

새로운 프로토콜에 대한 표현이지만 여전히 어떤 이름을 유효하고 비교 방법) IDNA 프로토콜은 애플리케이션 내에 완전히 포함되어 있습니다. 그것은 클라이언트-서버 또는 피어-투-피어 프로토콜이 아닙니다. 모든 것이 완료되었습니다.

응용 프로그램 자체 내부. DNS 해석기와 함께 사용하는 경우 라이브러리, IDNA는 응용 프로그램과 응용 프로그램 사이에 "shim"으로 삽입됩니다. ​

리졸버 라이브러리. DNS 영역에 이름을 쓰는 데 사용되는 경우 IDNA 이름이 영역에 커밋되기 직전에 사용됩니다. 이 문서의 섹션 4에 설명 된 두 가지 작업이 있습니다.

-ToASCII 작업은 IDN을 무언가에 보내기 전에 사용됩니다. ASCII 이름 (예 : 해석기)을 예상하거나 IDN을 작성하는 경우 ASCII 이름 (예 : DNS 마스터 파일)을 예상하는 위치로. -ToUnicode 연산은 사용자에게 이름을 표시 할 때 사용됩니다. 예를 들어 DNS 영역에서 얻은 이름입니다.

ToASCII 작업이 실패 할 수 있다는 점에 유의해야합니다. 그 경우 도메인 이름을 처리 할 때 실패하면 해당 도메인 이름을 사용할 수 없습니다.

국제화 된 도메인 이름으로 응용 프로그램은 이 실패를 처리하는 몇 가지 방법. IDNA에서는 구현시 다음을 사용하여 입력 문자열을 처리해야합니다.

Stringprep [STRINGPREP]의 프로필 인 Nameprep [NAMEPREP], 그런 다음 Punycode [PUNYCODE]를 사용합니다. IDNA의 구현은 반드시 Nameprep 및 Punycode를 완전히 구현합니다.​

Nameprep도 Punycode도 아닙니다. 선택 사항입니다.

용어 키워드 "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 이 문서의 "MAY"는 BCP에 설명 된대로 해석됩니다.

RFC 2119 [ RFC2119 ]. 코드 포인트는 문자와 관련된 정수 값입니다. 코딩 된 문자 세트. 유니 코드 [UNICODE]는 수십 개의 수천 개의 문자. 단일 유니 코드 코드 포인트는 다음과 같이 표시됩니다.

"U +"뒤에 4 ~ 6 개의 16 진수가오고 범위는 유니 코드 코드 포인트는 분리 된 두 개의 16 진수로 표시됩니다. 접두사없이 ".."로. ASCII는 US-ASCII [USASCII]를 의미하며 128을 포함하는 코드화 된 문자 집합입니다. 0..7F 범위의 코드 포인트와 연관된 문자. ​

유니 코드 ASCII의 확장입니다. 여기에는 모든 ASCII 문자가 포함되며 동일한 코드 포인트와 연관시킵니다. 이 문서에서 "LDH 코드 포인트"라는 용어는 ASCII 문자, 숫자 및 하이픈과 관련된 코드 포인트 마이너스; 즉, U + 002D, 30..39, 41..5A 및 61..7A입니다.

"LDH"는 "문자, 숫자, 하이픈"의 약어입니다. [STD13]은 "도메인 이름"과 "호스트 이름"에 대해 이야기하지만 많은 사람들이 용어를 같은 의미로 사용하십시오. 또한 [STD13]은 엄청나게 분명합니다. 정확한 정보를 알고 있다고 확신하는 많은 사람들 이러한 각 용어의 정의는 정의에 동의하지 않습니다. 에 이 문서에서는 "도메인 이름"이라는 용어가 일반적으로 사용됩니다.

이 문서는 호스트 이름을 참조 할 때마다 명시 적으로 [STD3]를 인용합니다. 거기에 정의 된 구문 제한. 레이블은 도메인 이름의 개별 부분입니다. 레이블은 일반적으로 점으로 구분되어 표시됩니다.

예 : 도메인 이름 "www.example.com"은 "www", "example"및 "com". ([STD13]에 설명 된 길이가 0 인 루트 레이블입니다. "www.example.com"과 같이 명시 적이어야합니다. 또는 암시 적 "www.example.com"은이 사양에서 레이블로 간주되지 않습니다.) IDNA는 텍스트 레이블에서 사용 가능한 문자 세트를 확장합니다.

이 문서의 나머지 부분에서 "라벨"이라는 용어는 "텍스트 레이블", "모든 레이블"은 "모든 텍스트 레이블"을 의미합니다.

"국제화 된 레이블"은 ToASCII가 작동 (섹션 4 참조)은 실패없이 적용 할 수 있습니다 ( UseSTD3ASCIIRules 플래그 설정 해제). 이것은 모든 ASCII 레이블이 [STD13] 길이 제한을 충족하는 것은 국제화 상표. 따라서 "국제화 된 레이블"이라는 용어는 일반화, 이전 ASCII 레이블과 새로운 비 ASCII 모두 수용 라벨. 대부분의 유니 코드 문자는 국제화 된 레이블, ToASCII는 일부 입력 문자열에 대해 실패합니다. 이러한 문자열은 유효한 국제화 된 레이블이 아닙니다. ​

"국제화 도메인 이름"(IDN)은 다음과 같은 도메인 이름입니다. 모든 레이블은 국제화 된 레이블입니다. 이것은 모든 ASCII 도메인 이름은 IDN입니다 (이는 ASCII가 아닌 문자를 포함하지 않는 IDN 이름). 이 문서는 "국제화 된 호스트"를 정의하지 않습니다.

ASCII 이름의 경우처럼 일부 DNS 영역 관리자는 DNS에 의해 부과 된 것 이상의 제한을 부과 할 수 있습니다. 또는 IDNA로 등록 될 수있는 문자 또는 문자열에 해당 영역의 레이블. 이러한 제한은 DNS 프로토콜 메시지의 구문 또는 의미; 이름에 대한 쿼리 일치하지 않는 레코드는 영역에없는 이유. 쿼리를 발행하는 클라이언트 또는 응답을 해석하는 것은 영역 별 제한 또는 규칙. IDNA에서 레이블의 동등성은 ToASCII의 관점에서 정의됩니다. 주어진 레이블에 대한 ASCII 형식을 구성하는 작업 또는 레이블이 이미 ASCII 레이블이 아니 었습니다. 레이블은 다음과 같이 정의됩니다. ​

ToASCII에 의해 생성 된 ASCII 형식 인 경우에만 동등합니다. 대소 문자를 구분하지 않는 ASCII 비교를 사용하여 일치합니다. ​

ASCII 레이블 이미 동등한 개념이 있습니다. 대문자와 소문자는 동등한 것으로 간주됩니다. 동등성에 대한 IDNA 개념은 그 오래된 개념의 확장. IDNA의 해당 레이블은 다음과 같습니다.

"foo"및 "Foo"와 같이 동일한 레이블의 대체 형식으로 처리됩니다. 동일한 레이블의 대체 형식으로 처리됩니다.

국제화 된 레이블을 기존 응용 프로그램에서 IDNA는 "ACE 레이블"을 사용합니다 (ACE는 ASCII를 나타냅니다. 호환 가능한 인코딩). ACE 레이블은 국제화 된 레이블입니다.

ASCII로 렌더링 할 수 있으며 ASCII로 렌더링 할 수없는 국제화 된 레이블입니다. 주어진 ASCII로 렌더링 할 수없는 국제화 된 레이블 인 ToASCII 작업은이를 동등한 ACE 레이블로 변환합니다 (반면 ASCII 레이블은 ToASCII에 의해 변경되지 않습니다. ​

ACE 레이블은 사용자에게 표시하기에 적합하지 않습니다. ToUnicode 작업은 레이블을 동등한 비 ACE 레이블로 변환합니다. 사실, ACE 레이블은 공식적으로 ToUnicode 작업이 변경됩니다 (ACE가 아닌 레이블은 ToUnicode). 모든 ACE 레이블은 다음에 지정된 ACE 접두사로 시작합니다. ​

섹션 5. ToASCII 및 ToUnicode 작업은 섹션 4. "ACE 접두사"는이 문서에서 ASCII 문자열로 정의됩니다. 모든 ACE 레이블의 시작 부분에 나타나는 문자. 그것은 섹션 5에 명시되어 있습니다. 이 문서에서 "도메인 이름 슬롯"은 프로토콜로 정의됩니다. 요소 또는 함수 인수 또는 반환 값 (등) 도메인 이름을 전달하도록 명시 적으로 지정됩니다. 도메인의 예 이름 슬롯에는 다음이 포함됩니다.

DNS 쿼리의 QNAME 필드; 이름 인수 gethostbyname () 라이브러리 함수의; 이메일 주소의 일부 전자 메일 메시지의 보낸 사람 : 필드에서 at 기호 (@)를 따릅니다.

헤더; 의 src 속성에있는 URI의 호스트 부분 HTML <IMG> 태그. 도메인을 포함하는 일반 텍스트 name은 도메인 이름 슬롯이 아닙니다. 예를 들어, 나타나는 도메인 이름 이메일 메시지의 일반 텍스트 본문에서 도메인을 차지하지 않습니다.

이름 슬롯. 이 문서에서 "IDN 인식 도메인 이름 슬롯"은 운반을 위해 명시 적으로 지정된 도메인 이름 슬롯 이 문서에 정의 된 국제화 된 도메인 이름. 그만큼 지정은 정적 일 수 있습니다 (예 : 프로토콜 또는 인터페이스) 또는 동적 (예 : 대화식 세션에서 협상). 이 문서에서 "IDN 비 인식 도메인 이름 슬롯"은 다음과 같이 정의됩니다.

IDN 인식 도메인 이름 슬롯이 아닌 모든 도메인 이름 슬롯. 분명히 여기에는 사양이 지정된 모든 도메인 이름 슬롯이 포함됩니다. IDNA보다 앞서 있습니다.

요구 사항 및 적용 가능성 3.1 요구 사항 IDNA 적합성은 다음 네 가지 요구 사항을 준수 함을 의미합니다. 1) 라벨 구분자로 도트를 사용할 때마다 문자는 점으로 인식해야합니다,

U + 002E (마침표), U + 3002 (표의 문자 마침표), U + FF0E (전각 마침표), U + FF61 (반각 표의 문자 마침표). 2) 도메인 이름이 IDN 비 인식 도메인 이름 슬롯에 들어갈 때마다 (섹션 2 참조), ASCII 문자 만 포함해야합니다.

주어진 국제화 도메인 이름 (IDN), 동등한 도메인 이름 이 요구 사항을 충족하는 것은 ToASCII 작동 (섹션 4 참조)을 각 라벨에 레이블 구분 기호로 사용되며 모든 레이블 구분 기호를 U + 002E. 3) 도메인 이름 슬롯에서 얻은 ACE 레이블은 숨겨야합니다.​

환경이 비 ACE를 처리 할 수있는 것으로 알려진 경우 사용자 ACE 양식이 명시 적으로 요청 된 경우를 제외하고 양식. 때 환경이 비 ACE를 처리 할 수 ​​있는지 여부를 알 수 없음 응용 프로그램은 ACE가 아닌 양식을 사용할 수 있습니다 (실패 할 수 있음). 제대로 표시되지 않는 등) 또는 ACE를 사용할 수 있습니다. (사용자에게는 이해하기 어려운 것처럼 보일 것입니다). ​

주어진 국제화 된 도메인 이름, 동등한 도메인 이름 ACE 레이블이없는 것은 ToUnicode를 적용하여 얻을 수 있습니다. 각 라벨에 작동 (섹션 4 참조). 요구 사항 2 및 3 둘 다 적용되며 요구 사항 2가 우선합니다. ​

두 라벨을 비교할 때마다 반드시 일치하는 것으로 간주되어야합니다. ​

동일한 경우에만, 즉 ASCII 형식 (ToASCII를 적용하여 얻음) 대소 문자를 구분하지 않는 일치 ASCII 비교. 두 이름을 비교할 때마다 해당 레이블이있는 경우에만 일치하는 것으로 간주됩니다.

이름이 동일한 형식의 레이블을 사용하는지 여부에 관계없이 일치 구분자. 3.2 적용 가능성 IDNA는 모든 도메인 이름 슬롯의 모든 도메인 이름에 적용 가능합니다. 명시 적으로 제외 된 경우를 제외하고. 이것은 IDNA가 이전의 많은 프로토콜에 적용 가능함을 의미합니다. ​

IDNA. 해당 프로토콜에서 도메인 이름 슬롯을 차지하는 IDN ASCII 형식이어야합니다 (섹션 3.1, 요구 사항 2 참조). 3.2.1. DNS 리소스 레코드 IDNA는 NAME 및 RDATA 필드의 도메인 이름에는 적용되지 않습니다. CLASS가 IN이 아닌 DNS 리소스 레코드입니다. 이 예외가 적용됩니다. ​

IN이 아닌 모든 클래스, 현재와 미래에 표준은 명시 적으로 IDNA. 현재 IDNA의 적용 가능성에 대한 다른 예외는 없습니다. DNS 리소스 레코드에; 그것은 전적으로 CLASS에 의존합니다. 유형. 이것은 새로운 유형이 정의 되더라도 그대로 유지됩니다. ​

새로운 유형이 복잡해 져야하는 설득력있는 이유가 없다면 유형별 규칙을 적용하여 중요합니다. 3.2.2. 도메인 이름에 저장된 비 도메인 이름 데이터 유형 IDNA를 사용하면 ASCII가 아닌 문자를 도메인 이름은 IDNA가 다른 데이터 유형에서 비 ASCII 문자 표현 도메인 이름에 저장됩니다. 예를 들어 이메일 주소 로컬 부분은 때때로 도메인 레이블에 저장됩니다 ( hostmaster@example.com 은 SOA의 RDATA 필드에서 hostmaster.example.com으로 표시됩니다. 기록). ​

IDNA는 기존 이메일 표준을 업데이트하지 않습니다. 로컬 부분에는 ASCII 문자 만 허용됩니다. 따라서 이메일 표준이 개정되어 현지에서 IDNA를 사용하도록 parts, 이메일 주소의 로컬 부분을 보유하는 도메인 레이블 ACE 접두사로 시작해서는 안되며, 시작하더라도 문자 그대로 시작되는 로컬 부분으로 해석됩니다. ACE 접두사. ​

변환 작업 애플리케이션이 도메인 이름을 IDN 비 인식 슬롯으로 변환하거나 사용자에게 표시됩니다. 이 섹션에서는 수행 할 단계를 지정합니다. ​

변환, ToASCII 및 ToUnicode 작업. ToASCII 또는 ToUnicode에 대한 입력은 유니 코드 코드 포인트의 시퀀스 (모든 ASCII 코드 포인트는 유니 코드 코드 포인트이기도합니다). ​

도메인 이름이 다음을 사용하여 표현되는 경우 유니 코드 또는 US-ASCII 이외의 문자 집합 인 경우 먼저 유니 코드로 트랜스 코딩됩니다. 전체 도메인 이름에서 시작하여 응용 프로그램이 변환을 수행하는 데 필요한 사항은 다음과 같습니다.

도메인 이름이 "저장된 문자열"인지 "쿼리인지 결정 [STRINGPREP]에 설명 된대로 문자열 "입니다.이 변환이 다음과 같은 경우 [STRINGPREP]의 "쿼리"규칙에서 다음 플래그를 설정합니다.

"AllowUnassigned". 2)에 설명 된대로 도메인 이름을 개별 레이블로 분할합니다. 섹션 3.1. 레이블에는 구분 기호가 포함되어 있지 않습니다. ​

각 라벨에 대해 제한 적용 여부 결정 호스트 이름 [STD3]의 ASCII 문자. (이미 신청 IDNA가 도입되기 전에 이러한 선택에 직면했으며 항상 똑같은 방식으로 결정을 계속하십시오. IDNA 이 선택과 관련하여 새로운 권장 사항이 없습니다.) 제한을 적용하려면 다음 플래그를 설정하십시오. ​

해당 레이블에 대해 "UseSTD3ASCIIRules". 4) ToASCII 또는 ToUnicode로 각 레이블 처리 적절한 작업. 일반적으로 ToASCII를 사용합니다. IDN을 인식하지 못하는 이름을 입력하려는 경우 슬롯이고 표시하는 경우 ToUnicode 작업을 사용합니다.

사용자에게 이름; 섹션 3.1은 적용 가능한 요구 사항. 5) 4 단계에서 ToASCII가 적용되었고 점이 라벨로 사용 된 경우 구분 기호를 사용하려면 모든 레이블 구분 기호를 U + 002E (마침표)로 변경합니다. 다음 두 하위 섹션은 ToASCII 및 ToUnicode를 정의합니다. 4 단계에서 사용되는 작업입니다.

프로토콜에 대한이 설명은 특정 프로 시저 이름, 이름을 사용합니다. 의 사양을 용이하게하기 위해 플래그 등 실험 계획안. 이 이름과 실제 단계 절차는 구현에 필요하지 않습니다. 사실, 에 지정된 것과 동일한 외부 동작을 갖는 구현 이 문서는이 사양을 준수합니다. 4.1 ToASCII ToASCII 작업은 일련의 유니 코드 코드 포인트를 사용합니다. 하나의 레이블을 구성하고이를 일련의 코드 포인트로 변환합니다. ​

ASCII 범위 (0..7F). ToASCII가 성공하면 원래 시퀀스 결과 시퀀스는 동일한 레이블입니다. ToASCII 작업이 실패 할 수 있다는 점에 유의해야합니다. ​

ToASCII 단계가 실패하면 실패합니다. ToASCII 작업의 단계가있는 경우 도메인 이름의 레이블에서 실패하면 해당 도메인 이름은 국제화 된 도메인 이름으로 사용됩니다. 거래 방법 이 오류는 응용 프로그램에 따라 다릅니다. ToASCII에 대한 입력은 일련의 코드 포인트입니다.

AllowUnassigned 플래그 및 UseSTD3ASCIIRules 플래그. 출력 ToASCII는 일련의 ASCII 코드 포인트이거나 실패입니다. 질환. ToASCII는 모든 코드 포인트 시퀀스를 변경하지 않습니다. 시작할 ASCII 범위 (실패 할 수 있음). 적용 ToASCII 작업을 여러 번 수행하면 다음과 동일한 효과가 있습니다. 한 번만 적용합니다. ToASCII는 다음 단계로 구성됩니다. ​

시퀀스에 ASCII 범위 밖의 코드 포인트가 포함 된 경우 (0..7F) 그런 다음 2 단계로 진행하고 그렇지 않으면 3 단계로 건너 뜁니다.

[NAMEPREP]에 지정된 단계를 수행하고 오류가 있으면 실패합니다. 오류. AllowUnassigned 플래그는 [NAMEPREP]에서 사용됩니다. ​

UseSTD3ASCIIRules 플래그가 설정된 경우 다음 검사를 수행합니다. (a) 비 LDH ASCII 코드 포인트가 없는지 확인합니다. 즉, 0..2C, 2E..2F, 3A..40, 5B..60 및 7B..7F가 없습니다. (b) 선행 및 후행 하이픈 마이너스가 없는지 확인합니다. 그 즉, 시작과 끝에 U + 002D가없는 것입니다.

순서.

시퀀스에 ASCII 범위 밖의 코드 포인트가 포함 된 경우 (0..7F) 그런 다음 5 단계로 진행하고 그렇지 않으면 8 단계로 건너 뜁니다. ​

시퀀스가 ​​ACE 접두사로 시작하지 않는지 확인합니다. ​

[PUNYCODE]의 인코딩 알고리즘을 사용하여 시퀀스를 인코딩하고 오류가 있으면 실패합니다.

ACE 접두사를 추가합니다. 8. 코드 포인트 수가 1 ~ 63 범위에 있는지 확인합니다. 포함한.​

- RFC 3490-애플리케이션에서 도메인 이름 국제화 (IDNA) **-1 로이어집니다,

ToUnicode/

​

#네트워크 워킹 그룹 #P Faltstrom #의견 요청 #3490 Cisco #카테고리 #Standards Track P Hoffman IMC #VPNC A Costello UC 버클리 #2003 년 3 월 응용 프로그램 #도메인 이름 국제화 (IDNA) #메모의 상태 #문서 #인터넷 표준 추적 프로토콜을 지정 #인터넷 커뮤니티 #토론 #제안 요청 개량 #인터넷"의 최신판을 참조 #표준화 상태 #공식 프로토콜 표준 "(STD 1) #프로토콜의 상태 #메모의 배포는 무제한 #저작권 고지 Copyright (C) The Internet Society (2003) #판권 소유 요약 #지금까지 #도메인 이름을 사용하는 표준 방법 #ASCII 레퍼토리 외부의 문자 #문서는 국제화 도메인 이름 (IDN) #처리를위한 IDNA #Internationalizing Domain Names in Applications #표준 방식 #IDN은 큰 문자를 사용 #레퍼토리 (유니 코드) #IDNA는 비 ASCII 문자를 이미 허용 된 ASCII 문자 만 사용하여 표시됩니다 #오늘은 호스트 이름 #이전 버전과 호환되는 표현은 DNS와 같은 기존 프로토콜에 필요하므로 IDN이 기존 인프라에 대한 변경없이 도입 #IDNA #자유 텍스트가 아닌 도메인 이름 처리만을 의미