Skip to main content
Resources

모든 gTLD 정책에서 IGO 및 INGO 식별자 보호

이 페이지는 다음과 같은 언어로 제공됩니다.

모든 번역 내용 및 문서의 영어 버전은 공식 버전이며, 영어 외 다른 언어의 번역 버전은 정보 제공용으로만 사용할 수 있습니다.

본 정책은 적십자 및 적신월 이름에 대한 이사회 채택 정책 권장안의 시행을 설명하기 위해 2020년 2월 18일에 개정되었습니다. 이전 버전과 개정안을 비교해 보십시오.

  1. 적용범위

    이 합의 정책은 적십자, 국제 올림픽 위원회(IOC), 국제 정부 기구(IGO) 및 국제 비정부 기구(INGO)의 특정 이름 보호와 관련하여 2014년 4월 30일 및 2019년 1월 27일 ICANN 이사회가 채택한 GNSO(Generic Names Supporting Organization) 정책 권장안을 포함하며, 이 권장안은 정부 자문 위원회(GAC)와 ICANN 이사회에 제공한 조언과 모순되지 않습니다.

  2. 정책발효일

    2.1. 2014년 4월 30일 이사회에서 승인된 적십자, IOC 및 IGO 이름의 경우 정책은 2018년 8월 1일까지 모든 gTLD 레지스트리 운영자 및 ICANN 공인 레지스트라에 유효합니다.

    2.2. 2014년 4월 30일에 이사회에서 승인된 INGO 이름의 경우 이 정책은 INGO 요청 시스템 규정이 발표된 후 12개월 동안 모든 gTLD 레지스트리 운영자 및 ICANN 공인 레지스트라에 적용됩니다.

    2.3. 2019년 1월 27일에 이사회에서 승인된 적십자 및 적신월 이름의 경우(예: 4절 "적십자: 국제 적십자사 및 적신월 운동 및 구성 요소) 2020년 8월 1일까지 모든 gTLD 레지스트리 운영자 및 ICANN 인가 레지스트라에 유효합니다.

    과도 조항: 2020년 8월 1일 또는 gTLD 레지스트리 운영자가 논평 [1]: 정책 다시 읽기에서 승인된 적십자 및 적신월 이름 목록의 시행을 마칠 때까지 재개된 RC recs가 2014 정책에 추가된 것을 명확히 하기 위해 이 날짜를 앞에 추가해야 한다고 생각합니다. 삭제됨: 삭제됨: 삭제됨: 2019년 1월 27일 이사회 중 가장 빠른 날짜에 gTLD 레지스트리 운영자는 2018년 8월 1일 현재 적십자 및 적신월 식별자 목록에 포함된 이름을 계속 예약해야 합니다. 명확히 하자면, 2020년 8월 1일부터 업데이트된 적십자 및 적신월 식별자 목록이 2018년 8월 1일 목록을 완전히 대체합니다. 두 목록에 대한 링크가 gTLD의 예약된 이름에 제공됩니다.

  3. 정의. 본 정책의 목적상, 관련 용어는 다음과 같이 정의합니다.

    3.1. 예약이란 등록을 보류하거나 레지스트리 운영자에게 할당하지만 제3자에게 등록하거나 DNS에서 위임하거나, 사용하거나, 활성화하거나, TLD 내에서 문자열을 사용할 수 있게 하는 것은 아닙니다.

    3.2. INGO 요청통지은 INGO 식별자 목록의 이름과 정확히 일치하는 도메인 이름을 등록하려고 시도하는 잠재적인 도메인 이름 등록자에게 레지스트라가 표시하는 관련 INGO의 정보가 포함된 통지를 의미합니다.

    3.3. INGO 요청서비스는 등록된 도메인 이름이 INGO 식별자 목록에 있는 INGO의 이름과 정확하게 일치한다는 사실을 도메인 이름 등록자와 관련 INGO에 통보하는 프로세스를 말합니다.

    3.4. INGO 요청시스템은 계약 당사자가 INGO 식별자 목록에 해당하는 DNS 라벨 데이터베이스에 액세스할 수 있도록 허용하고 알림을 위해 관련 프로세스에 대한 등록 정보를 제공하는 시스템을 의미합니다.

    3.5. INGO 식별자목록은 90일 INGO 요청 통지 프로세스에 참여할 수 있는 차상위 수준, 완전 일치, 보호된 INGO의 전체 이름 및 해당 DNS 라벨을 포함하는 목록을 나타냅니다.

    3.6. 적십자, IOC 및 IGO 식별자목록은 이 정책에 따라 특정 보호를 받도록 지정된 차상위 수준, 완전 일치, 보호된 적십자 및 IOC 조직의 전체 이름, IGO 및 해당 DNS 라벨을 포함하는 목록을 나타냅니다.

    3.7. 이 문서에서 "~해야 한다" "~해서는 안 된다" "~하는 것을 권장한다", "~하지 않는 것을 권장한다", "~할 수 있다"와 같은 키워드는 http://www.ietf.org/rfc/rfc2119.txt의 RFC 2119 설명에 따라 해석해야 합니다.

  4. 차상위수준에서적십자, IOC 및 IGO 전체이름예약

    4.1. 예약. gTLD의 예약 이름1 에 있는 적십자, IOC 및 IGO 식별자 목록에 기록된 모든 식별자의 DNS 라벨에 따라 모든 gTLD 레지스트리 운영자의 등록을 보류하거나 레지스트리 운영자에 차상위 수준 도메인 이름을 할당해야 합니다. 레지스트리 운영자를 TLD 레지스트리의 운영자로 지정하는 작업이 완료되면 이와 같이 보호된 모든 식별자를 ICANN에서 지정한 대로 이전해야 합니다. 레지스트리 운영자는 ICANN 인가 레지스트라를 사용하지 않고 이러한 이름을 자체 할당하여 갱신할 수 있으며, 이는 계약 6.1절의 목적을 위한 거래로 간주되지 않습니다.

    4.2. gTLD의기존등록. 적십자, IOC 및 IGO 식별자 목록과 정확히 일치하는 이름을 포함하는 도메인 이름이 본 합의 정책 발효일 전이나 적십자, IOC 및 IGO 식별자 목록에 라벨을 추가하기 전에 등록된 경우, 레지스트리 운영자가 도메인 이름의 갱신을 허용해야 하며 도메인 이름의 이전을 허용해야 합니다. 적십자, IOC 및 IGO 식별자 목록과 정확히 일치하는 이름을 포함하는 도메인 이름이 적십자, IOC 및 IGO 식별자 목록에 라벨을 추가하기 전에 등록된 후 삭제되면 레지스트리 운영자가 도메인 이름을 등록 보류하고 레지스트리 운영자에 도메인 이름을 할당해야 합니다.

    4.3. 적십자, IOC 및 IGO 조직등록. 적십자, IOC 및 IGO 조직은 식별자와 일치하는 도메인 이름의 등록을 요청할 수 있습니다. 그러지 않으면 이 정책에 따라 차상위 수준의 등록에서 보류됩니다. 레지스트리 운영자와 레지스트라는 적십자, IOC 및 IGO 조직이 예약한 이름을 등록하는 방법을 제공해야 합니다.2

    4.4. 적십자, IOC 및 IGO 식별자목록변경: ICANN에서 레지스트리 운영자에게 10일 이내에 통보하여 적십자, IOC 및 IGO 식별자 목록에 이름을 추가하거나 삭제할 수 있습니다. ICANN은 적십자, IOC 및 IGO 식별자 목록에 있는 이름의 제안된 변경사항과 관련하여 GAC 및 GNSO와 gTLD 예약 이름에 대해 협의합니다.

  5. 차상위수준의 INGO 요청서비스

    적용범위. INGO 요청 서비스는 본 합의 정책 발효일 후 위임된 gTLD에만 적용됩니다. 레지스트리 운영자와 레지스트라는 아래에 기술되어 있고 INGO 요청 시스템 규정3 에 지정된 대로 INGO 식별자 목록과 정확히 일치하는 INGO 이름과 해당 DNS 라벨을 위해 INGO 요청 서비스를 제공해야 합니다. INGO 식별자 이름과 해당 DNS 라벨은 INGO 식별자 목록4 에 있습니다.

    5.1. INGO 요청서비스

    5.1.1. 일반 등록6 중에 도메인 이름을 등록에 사용할 수 없는 경우 레지스트리 운영자가 효과적 할당5 전이나 도메인 이름을 등록할 수 있게 되는 처음 90일 동안 INGO 요청 서비스를 제공해야 합니다.

    5.1.2. 등록 절차 중 레지스트라는 등록을 실행하기 전에, INGO 요청 통지를 표시하여 등록하도록 요청한 이름이 INGO 식별자 목록의 이름과 정확하게 일치하고 해당 이름이 모든 gTLD 정책에서 ICANN이 보호하는 IGO 및 INGO 식별자가 될 수 있음을 잠재적 등록자에게 알려야 합니다.

    5.1.3. 레지스트라는 요청 통지 정보를 포함하여 INGO 요청 통지를 잠재적 도메인 이름 등록자에게 명확하고 확실하게 표시해야 하며, 잠재적 도메인 이름 등록자가 등록을 계속할지 문의해야 합니다.

    5.1.4. INGO 요청 통지는 레지스트라가 잠재적 등록 시점에 실시간으로 장래 도메인 이름 등록자에게 무료로 제공해야 하며 부록 A의 INGO 요청 통지에 지정된 형식이어야 합니다.

    5.1.5. 등록을 계속하려면 잠재적 도메인 이름 등록자가 NGO 요청 통지에 대해 확인을 전송해야 합니다(즉 수락 상자를 미리 선택하지 않아야 함).

    5.1.6. INGO 요청 통지는 레지스트라가 잠재적인 도메인 이름 등록자에게 영어로 제공해야 하며, 레지스트라가 등록 계약 시 사용한 언어로 잠재적인 도메인 이름 등록자에게 제공해야 합니다.

    5.1.7. 등록 시 레지스트리 운영자는 INGO 요청 시스템의 이름이 등록되었음을 나타내는 INGO 요청 시스템의 통지를 제공해야 합니다. 그러면 INGO 요청 시스템에서 해당 INGO에 이름이 등록되었음을 알리는 통지를 생성합니다. 등록된 이름에 대한 INGO 통지의 예는 부록 B에 나와 있습니다.

    5.1.8. INGO 요청 기간 동안 레지스트리 운영자가 TLD에 도메인 이름을 효과적으로 할당하기 위한 IDN 변형 정책을 수립한 경우 레지스트리 운영자는 변형 세트의 모든 라벨에 대한 알림을 제공해야 합니다.

    5.1.9. 레지스트리 운영자는 INGO 요청 서비스를 제공하기 전에 INGO 요청 시스템과의 성공적인 통합 테스트를 완료해야 합니다.

    5.1.10. INGO 식별자목록변경. INGO 식별자 목록에 이름을 추가하거나 삭제할 수 있습니다. ICANN은 INGO 식별자 목록에 있는 INGO 이름의 제안된 변경사항에 관해 유엔 경제사회국(United Nations Department of Economic)과 협의합니다.

부록

부록 A: 잠재적인도메인이름등록자에게표시되는 INGO 요청통지

귀하는 INGO(국제 비정부 기구) 식별자 목록에 있는 하나 이상의 INGO 이름과 정확히 일치하는 도메인 이름을 신청했기 때문에 이 INGO 요청 청구를 받았습니다.

귀하의 의도된 용도와 아래에 열거된 기록이 동일하거나 현저하게 중복되는지 여부에 따라 도메인 이름을 등록할 자격이 부여될 수도 있고 그렇지 않을 수도 있습니다.

아래 정보를 주의 깊게 읽으십시오. 질문이 있는 경우 변호사 또는 법률 전문가와 상담하여 도움을 받을 수 있습니다.

이 등록을 계속하고, 이 통지를 받았으며 이 통지를 아는 한 최대한 이해했다고 나타내면 귀하의 등록과 요청된 도메인 이름 사용은 INGO가 해당 이름에 대해 가질 수 있는 법적 권리를 침해하지 않습니다. 다음 기록이 INGO 요청 목록에 나열됩니다.

INGO 공식 명칭: <ingoNotice:ingoName>
INGO 영어 이름: <ingoNotice:ingoEnglishName>
INGO URL: <ingoNotice:ingoURL>

INGO 공식 명칭: <ingoNotice:ingoName>
INGO 영어 이름: <ingoNotice:ingoEnglishName>
INGO URL: <ingoNotice:ingoURL>7

부록 B: INGO가보호단체에보낸등록된이름통지

एक उदाहरण님,

다음 도메인 이름이 INGO 식별자 목록의 INGO 기록과 일치하고 도메인 이름을 등록할 수 있는 처음 90일 동안 등록되었으므로 이 등록된 이름의 통지가 전송되었습니다.

INGO 공식 명칭: एक उदाहरण

INGO 영어 이름: 예제 1

도메인 이름: exampleone.example

생성 일자: 2013-09-16T14:21:26.648Z

참고: 특정 상황에서 이러한 도메인 이름 중 하나 이상이 더 이상 등록되지 않을 수 있습니다. 도메인 이름은 언제든 삭제할 수 있습니다. 또한 등록 후 처음 5일 동안 삭제된 도메인 이름은 바로 다시 등록할 수 있게 됩니다. 이러한 조건 또는 유사한 조건으로 등록된 이름의 통지를 여러 개 받을 수 있습니다.

자세한 내용은 해당 레지스트리의 도메인 이름에 대한 등록 데이터 디렉토리 서비스(Whois) 레코드를 참조하십시오. gTLD 레지스트리 목록과 Whois 링크는 https://www.icann.org/en/resources/registries/listing에 있습니다.

실행 기록

  1. DNS 라벨변환규칙

    DNS 허용 문자 프레임워크를 준수하지 않는 보호된 식별자는 문자, 숫자 및 하이픈만 포함하는 DNS 라벨로 변환됩니다. 적십자, IOC, IGO 및 INGO 식별자 목록의 일부 이름에는 국제 도메인 이름 작성 시 사용되는 대체 언어 문자는 물론 DNS 라벨에서 허용되지 않는 공백이나 공간 문자가 포함됩니다. 따라서 DNS 라벨 변환 규칙은 이 이름을 DNS 허용 문자로 변환하도록 개발되었습니다(예: 보호된 조직 "Africa Unite"는 "africa-unite"와 "africaunite"로 변환되고 "Olímpico"는 "olimpico"가 아니라 "xn--olmpico-8ya"로 변환됨). DNS는 라벨 길이에 대한 제한도 설정합니다. 결과적으로 DNS 라벨은 라벨에 허용되는 문자 수를 초과하는 보호된 식별자에 할당되지 않습니다(예: 보호된 조직 "아르헨티나의 상업, 산업 및 생산 회의소(Chamber of Commerce, Industry and Production)"의 라벨 길이는 INGO의 60자 라벨("chamberofcommerceindustryandproductionoftheargentinerepublic") 요청에 부합하지만, 길이가 69자인 문자열("chamber-of-commerce-industry-and-production-of-the-argentine-republic")은 최대 허용 길이인 63자보다 김).

    1.1. 적십자, IOC, IGO 및 INGO 식별자를 DNS 라벨과 일치. 보호된 식별자는 다음 규칙에 따라 이 정책의 1, 2 또는 3섹션에서 보호하기 위해 DNS 라벨로 변환됩니다.

    1.1.1. 각 식별자를 UTF-8 문자열로 변환하고 소문자로 변환하거나 선두 또는 후미 하이픈을 모두 제거한 다음 표준화 형식 C로 정규화하십시오.8

    1.1.2. 결과 문자열이 유효한 LDH9 DNS 라벨10 이면 더 이상 변환할 필요가 없으며, 이 문자열이 최종 DNS 라벨입니다. 문자열이 US-ASCII 문자로만 구성된 경우 두 개의 라벨이 생성됩니다. (1) 비LDH 문자를 제거한 결과 생성되는 라벨, (2) 비LDH 문자를 하이픈으로 대체한 라벨. 두 경우 모두 두 개 이상의 인접한 하이픈으로 이루어진 클러스터는 하나의 하이픈만으로 대체됩니다.

    1.1.3. 문자열이 유효한 U-라벨이면,11 DNS 라벨은 해당 A-라벨이 됩니다.12

    1.1.4. 문자열이 US-ASCII 문자로만 구성되지 않은 경우 두 개의 사전 라벨이 생성됩니다. (1) 유효하지 않은 IDNA2008 문자를 제거하여 생성되는 사전 라벨, (2) 유효한 IDNA2008 문자를 하이픈으로 대체한 사전 라벨. 두 경우 모두 두 개 이상의 인접한 하이픈으로 이루어진 클러스터는 하나의 하이픈만으로 대체된 다음 A-라벨 양식으로 변환됩니다.

    1.1.5. 기타의 경우 또는 이 알고리즘을 통해 생성한 문자열의 길이가 1 ~ 63이 아니면 결과적으로 생성되는 DNS 라벨이 없습니다.

  2. DNS 라벨 형식

    2.1. 레지스트리 연산자가 예약해야 하는 라벨의 경우 ICANN에서 변환 결과 생성된 DNS 라벨을 기계 판독 가능 형식으로 레지스트리 운영자에게 제공합니다.

    2.2. ICANN은 목록의 변경 과정을 신속하게 하기 위해 레지스트리 운영자에게 보내는 통지를 최소한 두 부분으로 나누거나 해당 데이터 필드가 다음과 같은 내용을 포함하도록 합니다. i) 목록에 추가된 DNS 라벨. ii) 목록에서 제거된 DNS 라벨.

  3. INGO 식별자 목록의 출처

    3.1. INGO 식별자 목록의 이름은 유엔 경제 사회 이사회를 통해 유엔 경제 사회국에서 제공합니다.13

  4. 권한 보호 메커니즘 요구사항 적용

    4.1. 권한 보호 메커니즘 요구사항(RPM) 섹션 2.4.314 은 적십자, IOC 및 IGO 식별자 목록에 기록된 모든 식별자에 해당하는 차상위 수준 도메인 이름에는 적용되지 않습니다.

배경 설명

이 정책 개발 프로세스(PDP)는 적십자 및 IOC를 포함하여 특정 IGO 및 INGO의 식별자에 대한 보호 조항에 대한 정책 권장 사항을 개발하기 위해 시작되었습니다.

이 합의 정책은 2014년 4월 30일 ICANN 이사회에서 채택한 정책 권고 사항을 포함하며 GAC 자문과 일치하지 않습니다(자세한 내용은 https://www.icann.org/resources/board-material/resolutions-2014-04-30-en#2.a 참조). ICANN 이사회, GAC 및 GNSO 간에 차이가 조정되면 GAC 조언과 일치하지 않는 우수한 권장 사항이 적절하게 처리됩니다.

채택된 권고 사항은 특정 적십자, IOC 및 IGO 이름(관련 보호 단체를 위해 고안된 예외 절차 포함)의 최상위 및 차상위 수준 보호, 특정 INGO 이름에 대한 최상위 수준의 보호 및 기타 특정 INGO 이름에 대한 차상위 수준의 90일 요청 통지 프로세스와 관련됩니다.

이 정책은 차상위 수준의 DNS 라벨과 관련하여 계약 당사자에 대한 요구사항을 제공합니다. 채택된 권장 사항은 gTLD 문자열 위임과도 관련이 있습니다. gTLD 문자열 위임과 관련하여 ICANN에서는 관련 보호 단체가 gTLD를 신청할 때까지 위에 언급된 식별자에 해당하는 gTLD를 보유해야 합니다.


1 예약된 이름 목록은 다음에서 확인할 수 있습니다. https://www.icann.org/resources/pages/reserved-2013-07-08-en

2 TLD의 등록은 여전히​커뮤니티 기반 자격 요건 및 공공의 이해 약정 및 IDN 테이블을 포함하여 레지스트리 운영자의 등록 제한사항에 따라 달라집니다.

3 INGO 요청 규정은 다음에서 확인할 수 있습니다. https://www.icann.org/resources/pages/ingo-claims-system-specification-2018-01-16-en

4 INGO 식별자 목록은 다음에 있습니다. https://www.icann.org/resources/pages/ingo-identifier-list-2018-01-16-en

5 효과적 할당의 정의는 다음에서 확인할 수 있습니다. https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec.

6 일반 등록의 정의는 다음에서 확인할 수 있습니다. http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-14may14-en.pdf

7 보다 작음 또는 보다 큼 기호 사이의 요소는 INGO 요청 규정에 설명된 XML 통지의 XML 요소를 참조합니다. XML 통지는 등록자에게 표시된 통지를 생성하기 위해 레지스트라가 INGO 요청 시스템에서 검색합니다.

8 유니코드 컨소시움 "유니코드 표준 부록 #15: 유니코드 표준화 양식", 2009년 9월, http://www.unicode.org/reports/tr15/.

9 문자 숫자 하이픈. 자세한 내용은 RFC 5890 섹션 2.3.1(https://tools.ietf.org/html/rfc5890)을 참조하십시오.

10 자세한 내용은 RFC 1034 섹션 3.1을 참조하십시오. https://www.ietf.org/rfc/rfc1034.txt

11 RFC 5890을 참조하십시오. https://tools.ietf.org/html/rfc5890

12 RFC 5890을 참조하십시오. https://tools.ietf.org/html/rfc5890

13 UNDESA는 INGO(https://www.un.org/development/desa/en/)의 ECOSOC 목록(https://www.un.org/ecosoc/en/home)을 관리하는 유엔 경제 사회국(United Nations Department of Economic and Social Affairs)입니다.

14 권한 보호 요구사항은 다음에서 확인할 수 있습니다. http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-14may14-en.pdf

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."