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

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

ToUnicode ToUnicode 작업은 일련의 유니 코드 코드 포인트를 사용합니다.

 

하나의 레이블을 구성하고 일련의 유니 코드 코드 포인트를 반환합니다. 만약 입력 시퀀스는 ACE 형식의 레이블이고 결과는 ACE 형식이 아닌 동등한 국제화 된 레이블, 그렇지 않으면 원래 시퀀스는 변경되지 않고 반환됩니다.

 

ToUnicode는 실패하지 않습니다. 단계가 실패하면 원래 입력 시퀀스는 해당 단계에서 즉시 반환됩니다. ToUnicode 출력에는 입력보다 더 많은 코드 포인트가 포함되지 않습니다.

 

코드 시퀀스를 나타내는 데 필요한 옥텟 수 포인트는 사용 된 특정 문자 인코딩에 따라 다릅니다. ToUnicode에 대한 입력은 일련의 코드 포인트입니다. AllowUnassigned 플래그 및 UseSTD3ASCIIRules 플래그. 출력 ToUnicode는 항상 유니 코드 코드 포인트의 시퀀스입니다.

 

시퀀스의 모든 코드 포인트가 ASCII 범위 (0..7F)에있는 경우 그런 다음 3 단계로 건너 뜁니다. 2. [NAMEPREP]에 지정된 단계를 수행하고 오류가 있으면 실패합니다.

 

오류. (여기서 ToASCII의 3 단계도 수행하면 ToUnicode의 전반적인 동작에 영향을 주지만 그렇지 않습니다. 필요) AllowUnassigned 플래그는 [NAMEPREP]에서 사용됩니다.

 

시퀀스가 ​​ACE 접두사로 시작하는지 확인하고 시퀀스의 사본.

 

ACE 접두사를 제거합니다.

 

[PUNYCODE]의 디코딩 알고리즘을 사용하여 시퀀스를 디코딩하고 오류가 있으면 실패합니다. 이 결과의 사본을 저장하십시오. 단계. 6. ToASCII를 적용합니다.

 

단계의 결과가 단계에서 저장된 사본과 일치하는지 확인합니다. 3, 대소 문자를 구분하지 않는 ASCII 비교를 사용합니다.

 

5단계에서 저장 한 사본을 반환합니다.

 

ACE 접두사 변환 작업 (섹션 4)에 사용되는 ACE 접두사는 2 개입니다. 영숫자 ASCII 문자와 두 개의 하이픈 빼기 기호. 그것 이전 문서에서 이미 사용 된 접두사가 될 수 없습니다.

 

여기에는 "bl--", "bq--", "dq--", "lq--", "mq--", "ra--", "wq--"및 "zq--". ToASCII 및 ToUnicode 작업은 ACE 접두사는 대소 문자를 구분하지 않습니다.

 

IDNA의 ACE 접두사는 "xn--"또는 대문자입니다. 이는 ACE 레이블이 "xn--de-jg4avhby1noc0d"일 수 있음을 의미합니다. 여기서 "de-jg4avhby1noc0d"는 다음에 의해 생성되는 ACE 레이블의 일부입니다.

 

[PUNYCODE]의 인코딩 단계. 모든 ACE 레이블은 모든 레이블이 아닌 ACE 접두사로 시작합니다. ACE 접두사로 시작하는 것은 반드시 ACE 레이블입니다. 비 ACE ACE 접두사로 시작하는 레이블은 사용자를 혼란스럽게하고 SHOULD DNS 영역에서는 허용되지 않습니다.

 

DNS를 사용하는 일반적인 응용 프로그램에 대한 의미 IDNA에서 애플리케이션은 입력에 필요한 처리를 수행합니다. 사용자의 국제화 된 도메인 이름, 국제화 된 표시 도메인 이름을 사용자에게 제공하고 DNS의 입력 및 출력을 처리합니다. 및 도메인 이름을 전달하는 기타 프로토콜. 그들 사이의 구성 요소와 인터페이스를 나타낼 수 있습니다. 그림으로 : + ------ + | 사용자 | + ------ + ^ | 입력 및 표시 : 로컬 인터페이스 방법 | (펜, 키보드, 빛나는 인, ...) + ------------------- | ----------------------------- -+ | v | | + ----------------------------- + | | | 신청 | | | | (ToASCII 및 ToUnicode | | | | 작업 수 | | | | 여기에 전화) | | | + ----------------------------- + | | ^ ^ | 최종 시스템 | | | | | 해결 자에게 전화 : | | 애플리케이션 별 | | 에이스 | | 프로토콜 : | | v | ACE는 | | + ---------- + | 프로토콜 업데이트 | | | 해결사 | | 다른 처리 | | + ---------- + | 인코딩 | | ^ | | + ----------------- | ---------- | -------------------- -+ DNS 프로토콜 : | | 에이스 | | vv + ------------- + + --------------------- + | DNS 서버 | | 애플리케이션 서버 | + ------------- + + --------------------- + "응용 프로그램"이라는 레이블이 붙은 상자는 응용 프로그램이 도메인 이름을 레이블로 만들고 적절한 플래그를 설정하고 ToASCII 및 ToUnicode 작업. 이것은 섹션 4에 설명되어 있습니다.

 

애플리케이션 입력 및 표시 응용 프로그램은 모든 문자 집합을 사용하여 도메인 이름을 허용 할 수 있습니다.

 

응용 프로그램 개발자가 원하는 도메인 이름을 모든 문자 집합. 즉, IDNA 프로토콜은 사용자와 응용 프로그램 간의 인터페이스. IDNA 인식 응용 프로그램은 국제화 된 두 가지 형식의 도메인 이름 : 국제화 된 문자 집합 응용 프로그램 및 ACE 레이블로 지원됩니다. ACE 라벨은 표시되거나 입력에는 항상 ACE 접두사가 포함되어야합니다. 응용 프로그램은 ACE 레이블의 입력 및 표시를 허용 할 수 있지만 허용하지 않습니다.

 

특별한 목적을위한 인터페이스를 제외하고는 그렇게하는 것이 좋습니다. 디버깅을 위해 또는 다음과 같은 디스플레이 제한에 대처하기 위해 섹션 6.4에 설명되어 있습니다.

 

ACE 인코딩은 불투명하고보기 흉합니다. 따라서 절대적으로 필요한 사용자에게만 노출되어야합니다. 때문에 ACE 이름 레이블로 인코딩 된 이름 레이블은 인코딩 된 ASCII 문자 또는 적절한 디코딩 된 문자, 응용 프로그램에는 사용자가 선호하는 항목을 선택할 수있는 옵션이있을 수 있습니다.

 

표시 방법; 만약 그렇다면, ACE 렌더링은 기본. 도메인 이름은 종종 여러 곳에서 저장되고 전송됩니다. 에 대한 예를 들어, 메일 메시지 및 웹과 같은 문서의 일부입니다. 페이지. 그들은 다음과 같은 많은 프로토콜의 많은 부분에서 전송됩니다.

 

제어 명령과 SMTP 의 RFC 2822 본문 부분 및 HTTP의 헤더 및 본문 내용. 중요합니다 도메인 이름은 도메인 이름 슬롯과 프로토콜을 통해 전달되는 콘텐츠 처리 방법을 정의하는 프로토콜 및 문서 형식 문자 세트의 사양 또는 협상, 레이블은 프로토콜 또는 문서 형식에서 허용하는 모든 문자 집합. 만약 프로토콜 또는 문서 형식은 하나의 문자 집합 만 허용합니다.

 

레이블은 그 문자 세트에 주어집니다. 프로토콜 또는 문서 형식이 전송을 허용하는 모든 장소 국제화 된 레이블의 문자 수, 국제화 된 라벨은 모든 문자 인코딩을 사용하여 전송되어야하며 프로토콜 또는 문서 형식이 사용하는 이스케이프 메커니즘 장소. 도메인 이름 슬롯을 사용하는 모든 프로토콜에는 이미 용량이 있습니다.

 

ASCII 문자 집합에서 도메인 이름을 처리합니다. 따라서 ACE 레이블 (ToASCII로 처리 된 국제 레이블 작동)은 본질적으로 이러한 프로토콜에 의해 처리 될 수 있습니다.

 

애플리케이션 및 리졸버 라이브러리 응용 프로그램은 일반적으로 운영 체제의 기능을 사용할 때 DNS 쿼리를 해결합니다. 운영 체제의 기능은 다음과 같습니다. "리졸버 라이브러리"라고도하며 응용 프로그램은 프로그래밍 인터페이스 (API)를 통해 리졸버 라이브러리를 사용합니다.

 

오늘날 이러한 해석기 라이브러리는 ASCII, 응용 프로그램은 반드시 ToASCII 작업을 사용하는 리졸버 라이브러리. 받은 라벨 해석기 라이브러리에는 ASCII 문자 만 포함됩니다. 국제화 ASCII로 직접 표시 할 수없는 레이블은 ACE 형식을 사용합니다. ACE 레이블에는 항상 ACE 접두사가 포함됩니다.

 

운영 체제에는 다음을 수행하기위한 라이브러리 세트가있을 수 있습니다. ToASCII 작동. 이러한 라이브러리에 대한 입력은 하나 또는 응용 프로그램에서 사용되는 더 많은 문자 집합 (UTF-8 및 UTF-16은 거의 모든 운영 체제 및 스크립트에 대한 후보 특정 문자 세트는 현지화 된 운영 체제에 사용됩니다.) IDNA를 인식하는 응용 프로그램은 국제화 된 레이블 ([STD13] 및 [STD3]을 준수하는 레이블) 및 국제화 된 레이블.

 

새로운 버전의 리졸버 라이브러리는 미래는 다음과 같은 다른 문자 집합의 도메인 이름을 허용 할 수 있습니다. ASCII 및 애플리케이션 개발자는 언젠가 도메인뿐만 아니라 유니 코드로 된 이름뿐만 아니라 로컬 스크립트에서 새로운 API로 운영 체제의 해석기 라이브러리. 따라서 ToASCII 및 ToUnicode 작업은 이러한 새 버전 내에서 수행 될 수 있습니다. 리졸버 라이브러리. 확인자에게 전달되거나의 질문 섹션에 입력 된 도메인 이름 DNS 요청은 [STRINGPREP]의 "쿼리"규칙을 따릅니다. 6.3 DNS 서버 영역에 저장된 도메인 이름은 "저장된 문자열"규칙을 따릅니다.

 

[STRINGPREP]에서. 직접 표시 할 수없는 국제화 된 레이블의 경우 ASCII, DNS 서버는 ToASCII에서 생성 한 ACE 양식을 사용해야합니다. 조작. DNS 서버에서 제공하는 모든 IDN은 ASCII 만 포함해야합니다. 문자. 기존의 협상을 가능하게하는 신호 시스템 새로운 DNS 클라이언트와 서버는 앞으로 표준화 될 것입니다.

 

DNS 프로토콜 자체의 쿼리 인코딩은 UTF-8과 같은 다른 것에 ACE. 질문 여부 이것은 사용되어야하지만 별도의 문제이며 이 메모에서 논의했습니다.

 

원시 ACE 인코딩에 사용자 노출 방지 사용자에게 도메인 이름을 표시 할 수있는 모든 애플리케이션 gethostbyaddr 또는 메일의 일부와 같은 도메인 이름 슬롯 헤더, 사용자가 볼 수 없도록하려면 업데이트해야합니다.

 

에이스. 응용 프로그램이 ToUnicode를 사용하여 ACE 이름을 디코딩하지만 표시 할 수없는 경우 디코딩 된 이름의 모든 문자 (예 : 이름이 출력 시스템이 표시 할 수없는 문자가 포함 된 경우 응용 프로그램은 ACE 형식으로 이름을 표시해야합니다 (항상 ACE 접두사) 대체 이름을 표시하는 대신 문자 (U + FFFD). 이것은 사용자가 이름을 다른 프로그램으로 올바르게 전송하십시오. 프로그램 기본적으로 모든 문자를 표시 할 수없는 경우 ACE 양식을 표시합니다.

 

이름 레이블에는 이름을 표시하는 메커니즘도 있어야합니다. ToUnicode 작업에 의해 생성되는 가능한 위치 및 대체 문자 표시 할 수 없습니다.

 

ToUnicode 작업은 유효한 ACE가 아닌 레이블을 변경하지 않습니다. 레이블은 ACE 접두사로 시작하는 경우에도 마찬가지입니다. ToUnicode가 레이블이 여전히 ACE 접두사로 시작하는 경우 적용되었습니다.

 

유효한 ACE 레이블이 아니고 ToUnicode에 의해 생성 된 중간 유니 코드 문자열. 6.5 IDN 도메인 이름의 DNSSEC 인증 DNS Security [ RFC2535 ]는 암호화를 제공하는 방법입니다.

 

DNS 메시지와 함께 확인 정보. 공개 키 암호화는 디지털 서명과 함께 사용되어 도메인 정보 요청자에게 인증 수단 제공 데이터 소스. 이렇게하면 다음으로 추적 할 수 있습니다. 신뢰할 수있는 소스, 직접 또는 신뢰 체인을 통해 정보 소스를 DNS 계층 구조의 맨 위로 올립니다.

 

IDNA는 DNS가 제공하는 모든 국제 도메인 이름을 지정합니다. ASCII로 직접 표현할 수없는 서버는 ACE를 사용해야합니다. ToASCII 작업에 의해 생성 된 양식. 이 작업은 영역이 개인 키로 서명되기 전에 수행됩니다. 존. 이 순서 때문에 다음을 인식하는 것이 중요합니다.

 

DNSSEC는 유니 코드 형식이 아닌 ASCII 도메인 이름을 인증합니다. 유니 코드 형식과 ASCII 형식 간의 매핑. 에서 DNSSEC가있는 경우 영역에서 서명해야하는 이름입니다. 검증되어야합니다. 이로 인해 IDNA를 배포하는 사이트가 DNSSEC는 특수 목적의 프록시 또는 전달자가 사용자 입력을 IDN으로 변환하는 것은 해결 흐름의 이전이어야합니다. DNSSEC가 작동하는 DNSSEC 인증 네임 서버보다.

 

이름 서버 고려 사항 기존 DNS 서버는 비 데이터 처리를위한 IDNA 규칙을 모릅니다.

 

ASCII 형식의 IDN이므로이를 차단해야합니다. 이름이 DNS 서버에 들어갈 수있는 모든 기존 채널 데이터베이스 (예 : 마스터 파일 [STD13] 및 DNS 업데이트 메시지 [ RFC2136 ]) IDNA보다 이전이므로 IDN을 인식하지 못하므로 이 문서의 섹션 요구 사항 2는 필요한 국제화 된 도메인 이름이 이러한 채널을 통한 DNS 서버 데이터베이스는 이미 동등한 ASCII 형식으로 변환됩니다. 하나의 ASCII 인코딩 만 있어야합니다.

 

특정 도메인 이름. ToASCII의 디자인과 ToUnicode 작업, ASCII로 디코딩하는 ACE 레이블이 없습니다. 레이블이므로 이름 서버는 여러 ASCII를 포함 할 수 없습니다. 동일한 도메인 이름의 인코딩. [ RFC2181 ] 도메인 레이블이 다음을 넘어서는 옥텟을 포함하도록 명시 적으로 허용 ASCII 범위 (0..7F)이며이 문서는이를 변경하지 않습니다. 그러나 옥텟에 대한 정의 된 해석은 없습니다.

 

문자로 80..FF. 이러한 옥텟을 포함하는 레이블이 반환되는 경우 애플리케이션에 예측할 수없는 동작이 발생할 수 있습니다. ASCII 형식 ToASCII에 의해 정의 된 유일한 표준 표현입니다.

 

현재 DNS 프로토콜의 국제화 된 레이블. 8. 루트 서버 고려 사항 IDN은 현재 도메인 이름보다 다소 길 수 있으므로 루트 서버에 필요한 대역폭은 소량. 또한 IDN에 대한 쿼리 및 응답은 오늘날 일반적인 쿼리보다 다소 길기 때문에 더 많은 쿼리와 응답은 UDP 대신 TCP로 강제로 이동할 수 있습니다. 9. 참고 문헌

 

9.1 표준 참조 [ RFC2119 ] Bradner, S., "RFC에서 사용하는 키워드 요구 수준 ", BCP 14, RFC 2119 , 1997 년 3 월. [STRINGPREP] Hoffman, P. 및 M. Blanchet, "준비 국제화 된 문자열 ( "stringprep") ", RFC 3454 , 2002 년 12 월. [NAMEPREP] Hoffman, P. 및 M. Blanchet, "Nameprep : Stringprep IDN (Internationalized Domain Names) 프로필 ", RFC 3491, 2003 년 3 월. [PUNYCODE] Costello, A., "Punycode : A Bootstring encoding of 국제화 도메인 이름과 함께 사용하기위한 유니 코드 Applications (IDNA) ", RFC 3492 , 2003 년 3 월. [STD3] Braden, R., "인터넷 호스트에 대한 요구 사항- Communication Layers ", STD 3, RFC 1122 및 "인터넷 호스트에 대한 요구 사항-응용 프로그램 및 Support ",

 

STD RFC 1123 , 1989 년 10 월. [STD13] Mockapetris, P., "도메인 이름-개념 및 시설 ", STD 13, RFC 1034 및"도메인 이름- 구현 및 사양 ", STD 13, RFC 1035 , 1987 년 11 월.

 

정보 참조 [ RFC2535 ] Eastlake, D., "도메인 이름 시스템 보안 확장", RFC 2535 , 1999 년 3 월. [ RFC2181 ] Elz, R. 및 R. Bush, "DNS에 대한 설명 Specification ", RFC 2181 , 1997 년 7 월. [UAX9] Unicode Standard Annex # 9, The Bidirectional Algorithm, < http://www.unicode.org/unicode/reports/tr9/ >. [UNICODE] 유니 코드 컨소시엄. 유니 코드 표준, 버전 3.2.0은 유니 코드 표준, 버전 3.0에 의해 정의됩니다. (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), Unicode Standard Annex # 27에 의해 수정 됨 : Unicode

 

( http://www.unicode.org/reports/tr27/ ) 및 유니 코드 표준 부록 #유니 코드

 

( http://www.unicode.org/reports/tr28/ ). [USASCII] Cerf, V., "네트워크 교환을위한 ASCII 형식", RFC 1969 년 10 월 20 일. 10. 보안 고려 사항 인터넷 보안은 부분적으로 DNS에 의존합니다. 따라서 모든 변경 DNS의 특성에 따라 대부분의 보안을 변경할 수 있습니다. 인터넷. 이 메모는 문자를 인코딩하는 알고리즘을 설명합니다.

 

STD3 및 STD13에 따라 옥텟 값으로 유효하지 않습니다. 유효한. 문자열 길이 증가 또는 신규와 같은 보안 문제 없음 허용되는 값은 인코딩 프로세스 또는 ACE 인코딩에 의해 도입 된 값과는 별도로 이러한 인코딩 된 값 그 자체. 도메인 이름은 사용자가 인터넷을 식별하고 연결하는 데 사용됩니다.

 

서버. 사용자가 다음과 같은 경우 인터넷 보안이 손상됩니다. 하나의 국제화 된 이름을 입력하는 것은 다른 국제화 된 서버의 다른 해석을 기반으로 도메인 이름. 시스템이 ASCII 및 유니 코드 이외의 로컬 문자 집합을 사용하는 경우 이 사양은 로컬 문자 집합 및 유니 코드는 응용 프로그램까지. 다른 경우 응용 프로그램 (또는 한 응용 프로그램의 다른 버전)은 다른 트랜스 코딩 규칙은 동일한 이름을 해석 할 수 있습니다.

 

다른 서버에 연결하십시오. 이 문제는 로컬을 취하지 않는 TLS와 같은 보안 프로토콜로 해결됩니다. 문자 세트를 고려합니다. 이 문서는 일반적으로 [NAMEPREP], [PUNYCODE]를 참조하므로 및 [STRINGPREP], 여기에는 이들의 보안 고려 사항이 포함됩니다.

 

문서도. 이 사양이 최신 유니 코드를 사용하도록 업데이트 된 경우 또는시기 정규화 테이블, 새 정규화 테이블은 이전 버전과 비교하여 이전 버전과 호환되지 않는 변경 사항을 발견했습니다. 만약 그러한 변경 사항이 있으면 어떻게 든 처리해야합니다. 보안 및 운영상의 영향이있을 것입니다.

 

행동 양식 충돌을 처리하기 위해 이전 정규화를 유지하는 것이 포함될 수 있습니다. 또는 작동 수단을 통해 상충되는 캐릭터를 처리하거나 다른 방법. 구현은 다음보다 최신 정규화 테이블을 사용해서는 안됩니다. 이 문서에서 참조한 것입니다. 운영 체제에서 제공 할 수 있습니다.

 

응용 프로그램이 확실하지 않은 경우 운영중인 정규화 테이블의 버전 시스템에서 응용 프로그램은 정규화 테이블을 포함해야합니다. 그 자체. 참조 된 테이블 이외의 정규화 테이블 사용 이 사양에서 보안 및 운영 의미. 시각적으로 보이는 캐릭터 간의 혼동을 방지하기 위해 유사하게 구현이 시각적 도메인 이름에 여러 스크립트가 포함되어 있음을 나타냅니다.

 

이러한 메커니즘을 사용하여 이름에 간체 및 번체 한자 또는 0 구분 그리고 O와 l에서 하나. DNS 영역 관리자가 제한을 적용 할 수 있음 (섹션 2의 제한 사항에 따라) 동음 이의어. 도메인 이름 (또는 그 일부)은 때때로 특권 또는 반 권한 도메인 세트. 그러한 상황에서 그것은 비교가 적절하게 수행되는 것이 특히 중요합니다.

 

요구 사항 4에 명시되어 있습니다. 이미 ASCII로 된 레이블의 경우 형식, 적절한 비교는 동일한 대소 문자를 구분하지 않습니다. 항상 ASCII 레이블에 사용되는 ASCII 비교입니다.

 

IDNA의 도입은 시작하는 기존 레이블이 ACE 접두사를 사용하고 ToUnicode에 의해 변경됩니다. 자동으로 ACE 레이블이되며 다음과 같은 것으로 간주됩니다. 비 ASCII 레이블 (영역의 의도 여부에 관계없이) 관리자 또는 등록자.

 

IANA 고려 사항 IANA는 IESG와 협의하여 ACE 접두사를 할당했습니다.

 

저자 주소 Patrik Faltstrom 시스코 시스템 Arstaangsvagen 31 J S-117 43 스톡홀름 스웨덴 이메일 : paf@cisco.com 폴 호프만 인터넷 메일 컨소시엄 및 VPN 컨소시엄 127 세 그레 플레이스 Santa Cruz, CA 95060 USA 이메일 : phoffman@imc.org 아담 M. 코스텔로 캘리포니아 대학교 버클리 URL : http://www.nicemice.net/amc/

 

전체 저작권 성명 Copyright (C) The Internet Society (2003). 판권 소유. 이 문서와 그 번역본은 복사 및 제공 될 수 있습니다. 기타 및 이에 대해 언급하거나 설명하는 파생물 또는 구현 지원을 준비, 복사, 게시 할 수 있습니다. 제한없이 전체 또는 일부 배포 종류, 위의 저작권 표시 및이 단락이 그러한 모든 사본 및 파생물에 포함됩니다. 그러나 이것은 문서 자체는 제거하는 등 어떤 방식으로도 수정할 수 없습니다.

 

Internet Society 또는 기타에 대한 저작권 고지 또는 참조 목적을 위해 필요한 경우를 제외하고 인터넷 조직 인터넷 표준을 개발하는 경우 절차는 인터넷 표준 프로세스에 정의 된 저작권은 따르거나 필요에 따라 다른 언어로 번역 영어. 위에 부여 된 제한된 권한은 영구적이며 Internet Society 또는 그 후임자 또는 양수인에 의해 취소되었습니다.

 

이 문서와 여기에 포함 된 정보는 "있는 그대로"기반과 인터넷 사회와 인터넷 공학 TASK FORCE는 다음을 포함한 모든 명시 적 또는 묵시적 보증을 부인합니다. 그러나 정보의 사용에 대한 보증에 국한되지 않습니다.

 

여기에서는 다음과 같은 권리 또는 묵시적 보증을 침해하지 않습니다. 상품성 또는 특정 목적에의 적합성. 승인 RFC 편집기 기능에 대한 자금은 현재 인터넷 사회.  

 

사용자 기여 :

이 RFC에 대해 의견을 말하거나 질문하거나이 주제에 대한 새 정보를 추가하십시오.

이름:

이메일:

 내 이메일을 공개적으로 표시

인간 검증 :

공개 댓글 : (50-4000 자)

 

#Internet Society 도메인이름 #메커니즘 #권리 #묵시적 보증을 침해하지 않습니다 #상품성 #특정 목적에의 적합성 #승인 RFC 편집기 기능에 대한 자금 #현재 인터넷 사회 #저자 주소 #Patrik Faltstrom #시스코 시스템 #Arstaangsvagen 31 J S-117 43 #스톡홀름 스웨덴 이메일 #폴 호프만 #인터넷 메일 컨소시엄 #VPN 컨소시엄 127 세 그레 플레이스 Santa Cruz CA 95060 USA 이메일 #아담 M 코스텔로 #캘리포니아 대학교 버클리 URL #전체 저작권 성명 #Copyright (C) The Internet Society (2003) #판권 소유 #문서 번역본 #복사 및 제공 #언급하거나 설명하는 파생물 #구현 지원을 준비 #복사 #게시 #제한없이 전체  #일부 배포 종류 #저작권 표시 및이 단락 #모든 사본 및 파생물에 포함 #문서 자체는 제거하는 등 어떤 방식으로도 수정할 수 없습니다 #RFC에 대해 의견 #상품성 #특정 목적에의 적합성 #승인 RFC 편집기 기능 #ASCII 레이블 #유니 코드 표준 버전 #저작권표시 #트랜스 코딩 규칙 #인터넷보안 #저작권 고지 #이메일을 공개적으로 표시 #DNS의 특성 #사양 #최신 유니 코드를 사용 #업데이트 된 경우 #정규화 테이블 #새 정규화 테이블 #이전 버전과 비교 #이전 버전과 호환 #보안 프로토콜로 해결 #애플리케이션