네트워크 작업 그룹 A. Phillips, 편집자 의견 요청 문서: 5646 Lab126 BCP: 47 M. Davis, 편집자 폐기 대상: 4646 Google 범주: 현재 최선의 관행 2009년 9월 언어 식별용 태그 초록 이 문서는 정보 객체에서 사용된 언어를 나타내는 것이 바람직한 경우에 사용할 언어 태그의 구조, 내용, 구성 및 의미를 설명합니다. 또한 언어 태그에서 사용할 값을 등록하는 방법과 사적 교환을 위한 사용자 정의 확장을 생성하는 방법을 설명합니다. 이 메모의 상태 이 문서는 인터넷 커뮤니티를 위한 인터넷 현재 최선의 관행을 규정하며, 개선을 위한 논의와 제안을 요청합니다. 이 메모는 제한 없이 배포할 수 있습니다. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Phillips & Davis 현재 최선의 관행 [1페이지]
RFC 5646 언어 태그 2009년 9월 목차 1. 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 언어 태그 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. 구문 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. 언어 태그의 형식 . . . . . . . . . . . . . . . . . . . 6 2.2. 언어 하위 태그의 출처 및 해석 . . . . . . . . . . . . . . 8 2.2.1. 기본 언어 하위 태그 . . . . . . . . . . . . . . . . . . 9 2.2.2. 확장 언어 하위 태그 . . . . . . . . . . . . . . . . . 11 2.2.3. 문자 체계 하위 태그 . . . . . . . . . . . . . . . . . 12 2.2.4. 지역 하위 태그 . . . . . . . . . . . . . . . . . . . . 13 2.2.5. 변형 하위 태그 . . . . . . . . . . . . . . . . . . . . 15 2.2.6. 확장 하위 태그 . . . . . . . . . . . . . . . . . . . . 16 2.2.7. 사적 사용 하위 태그 . . . . . . . . . . . . . . . . . 18 2.2.8. 기존 및 중복 등록 . . . . . . . . . . . . . . . . . . 18 2.2.9. 적합성 클래스 . . . . . . . . . . . . . . . . . . . . . 19 3. 레지스트리 형식 및 유지 관리 . . . . . . . . . . . . . . . . . 21 3.1. IANA 언어 하위 태그 레지스트리의 형식 . . . . . . . . . 21 3.1.1. 파일 형식 . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.2. 레코드 및 필드 정의 . . . . . . . . . . . . . . . . . 23 3.1.3. Type 필드 . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.4. Subtag 및 Tag 필드 . . . . . . . . . . . . . . . . . . 26 3.1.5. Description 필드 . . . . . . . . . . . . . . . . . . . 26 3.1.6. Deprecated 필드 . . . . . . . . . . . . . . . . . . . . 28 3.1.7. Preferred-Value 필드 . . . . . . . . . . . . . . . . . 28 3.1.8. Prefix 필드 . . . . . . . . . . . . . . . . . . . . . . 31 3.1.9. Suppress-Script 필드 . . . . . . . . . . . . . . . . . 32 3.1.10. Macrolanguage 필드 . . . . . . . . . . . . . . . . . 32 3.1.11. Scope 필드 . . . . . . . . . . . . . . . . . . . . . 33 3.1.12. Comments 필드 . . . . . . . . . . . . . . . . . . . . 34 3.2. 언어 하위 태그 검토자 . . . . . . . . . . . . . . . . . . 35 3.3. 레지스트리 유지 관리 . . . . . . . . . . . . . . . . . . 35 3.4. IANA 레지스트리 항목의 안정성 . . . . . . . . . . . . . 36 3.5. 하위 태그 등록 절차 . . . . . . . . . . . . . . . . . . . 41 3.6. 등록 가능성 . . . . . . . . . . . . . . . . . . . . . . . 46 3.7. 확장 및 확장 레지스트리 . . . . . . . . . . . . . . . . . 49 3.8. 언어 하위 태그 레지스트리 업데이트 . . . . . . . . . . 52 3.9. 하위 태그 레지스트리의 적용 가능성 . . . . . . . . . . 52 4. 언어 태그의 구성 및 처리 . . . . . . . . . . . . . . . . . . 53 4.1. 언어 태그 선택 . . . . . . . . . . . . . . . . . . . . . . 53 4.1.1. 포괄되는 언어에 태그 지정 . . . . . . . . . . . . . 58 4.1.2. 확장 언어 하위 태그 사용 . . . . . . . . . . . . . . 59 4.2. 언어 태그의 의미 . . . . . . . . . . . . . . . . . . . . 61 4.3. 언어 목록 . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4. 길이 고려 사항 . . . . . . . . . . . . . . . . . . . . . 63 4.4.1. 제한된 버퍼 크기에서의 작업 . . . . . . . . . . . . 64 4.4.2. 언어 태그 자르기 . . . . . . . . . . . . . . . . . . 65 4.5. 언어 태그 정규화 . . . . . . . . . . . . . . . . . . . . 66 Phillips & Davis 현재 최선의 관행 [2페이지]
RFC 5646 언어 태그 2009년 9월 4.6. 사적 사용 하위 태그에 대한 고려 사항 . . . . . . . . . . 68 5. IANA 고려 사항 . . . . . . . . . . . . . . . . . . . . . . . . 69 5.1. 언어 하위 태그 레지스트리 . . . . . . . . . . . . . . . . 69 5.2. 확장 레지스트리 . . . . . . . . . . . . . . . . . . . . . 71 6. 보안 고려 사항 . . . . . . . . . . . . . . . . . . . . . . . 71 7. 문자 집합 고려 사항 . . . . . . . . . . . . . . . . . . . . . 72 8. RFC 4646에서의 변경 사항 . . . . . . . . . . . . . . . . . . 73 9. 참고 문헌 . . . . . . . . . . . . . . . . . . . . . . . . . . 76 9.1. 규범적 참고 문헌 . . . . . . . . . . . . . . . . . . . . . 76 9.2. 정보 제공용 참고 문헌 . . . . . . . . . . . . . . . . . . 78 부록 A. 언어 태그의 예(정보 제공용) . . . . . . . . . . . . . . 80 부록 B. 등록 양식의 예 . . . . . . . . . . . . . . . . . . . . 82 부록 C. 감사의 말 . . . . . . . . . . . . . . . . . . . . . . 83 1. 소개 과거와 현재를 통틀어 지구상의 인간은 수많은 언어를 사용해 왔습니다. 정보를 제공하거나 요청할 때 사용되는 언어를 식별하고자 하는 데에는 여러 가지 이유가 있습니다. 정보 항목의 언어나 사용자의 언어 기본 설정은 적절한 처리를 적용할 수 있도록 식별해야 하는 경우가 많습니다. 예를 들어 웹 브라우저에서 사용자의 언어 기본 설정을 사용하여 적절한 웹 페이지를 선택할 수 있습니다. 언어 정보는 서로 다른 언어로 된 콘텐츠의 처리 또는 이해를 돕기 위해 도구(예: 사전) 중에서 선택하는 데에도 사용할 수 있습니다. 특정 정보 콘텐츠에 사용된 구체적인 언어에 대한 지식은 철자 검사, 컴퓨터 합성 음성, 점자 전사 또는 고품질 인쇄 렌더링과 같은 일부 처리 유형에서 유용하거나 심지어 필요할 수도 있습니다. 사용된 언어를 나타내는 한 가지 방법은 정보 콘텐츠에 식별자 또는 "태그"를 붙이는 것입니다. 이러한 태그는 정보 콘텐츠를 선택할 때 사용자의 기본 설정을 지정하거나 콘텐츠 및 관련 리소스의 추가 속성을 표시하는 데에도 사용할 수 있습니다. 때때로 언어 태그는 콘텐츠의 추가적인 언어 속성을 나타내는 데 사용됩니다. 예를 들어 문서나 리소스에 사용된 방언, 문자 체계 또는 철자법에 관한 구체적인 정보를 표시하면 사용자가 이해할 수 있는 형태로 정보를 얻을 수 있으며, 주어진 콘텐츠를 적절한 형식이나 스타일로 처리하거나 렌더링하는 데 중요할 수도 있습니다. 이 문서는 특정 식별자 메커니즘(언어 태그)과 태그를 구성하는 데 Phillips & Davis 현재 최선의 관행 [3페이지]
RFC 5646 언어 태그 2009년 9월 사용할 값에 대한 등록 기능을 규정합니다. 또한 사적 사용 값과 향후 확장을 위한 메커니즘도 정의합니다. 이 문서는 [RFC4646]을 대체합니다([RFC3066]을 폐기했으며, 해당 문서는 다시 [RFC1766]을 대체했습니다). 이 문서는 [RFC4647]과 함께 BCP 47을 구성합니다. 이 문서의 변경 사항 목록은 8절을 참조하십시오. 이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"이라는 핵심 단어는 [RFC2119]에 설명된 대로 해석해야 합니다. 2. 언어 태그 언어 태그는 의사소통을 목적으로 음성, 문자, 수어 또는 기타 방식으로 전달되는 언어를 식별하는 데 사용됩니다. 여기에는 구성 언어와 인공 언어가 포함되지만, 프로그래밍 언어와 같이 주로 인간의 의사소통을 목적으로 하지 않는 언어는 제외됩니다. 2.1. 구문 언어 태그는 하나 이상의 "하위 태그" 시퀀스로 구성되며, 각 하위 태그는 전체 태그가 식별하는 언어의 범위를 더욱 구체화하거나 좁힙니다. 각 하위 태그는 영숫자 문자(문자 및 숫자)의 시퀀스이며, 태그 안의 다른 하위 태그와 하이픈("-", [Unicode] U+002D)으로 구별되고 분리됩니다. 하위 태그에는 여러 유형이 있으며, 각각 길이, 태그 내 위치 및 내용으로 구별됩니다. 즉, 각 하위 태그의 유형은 이러한 특징만으로 인식할 수 있습니다. 따라서 특정 하위 태그 값을 인식하지 못하더라도 하위 태그에서 일부 의미 정보를 추출하여 할당할 수 있습니다. 그러므로 언어 태그 처리기는 일반적인 검색 및 일치 작업을 수행하기 위해 유효한 태그 또는 하위 태그 목록(즉, IANA 언어 하위 태그 레지스트리의 특정 버전 사본)을 보유할 필요가 없습니다. 하위 태그 구조에서 의미를 추론하는 이러한 기능의 유일한 예외는 아래의 'regular' 및 'irregular' 생성 규칙에 나열된 기존 태그입니다. 이러한 태그는 [RFC3066]에 따라 등록되었으며 절대 변경되지 않는 고정 목록입니다. ABNF [RFC5234]로 표현한 언어 태그의 구문은 다음과 같습니다. Language-Tag = langtag ; 일반 언어 태그 / privateuse ; 사적 사용 태그 / grandfathered ; 기존 태그 Phillips & Davis 현재 최선의 관행 [4페이지]
RFC 5646 언어 태그 2009년 9월 langtag = language ["-" script] ["-" region] *("-" variant) *("-" extension) ["-" privateuse] language = 2*3ALPHA ; 가장 짧은 ISO 639 코드 ["-" extlang] ; 뒤에 오는 경우가 있는 ; 확장 언어 하위 태그 / 4ALPHA ; 또는 향후 사용을 위해 예약 / 5*8ALPHA ; 또는 등록된 언어 하위 태그 extlang = 3ALPHA ; 선택된 ISO 639 코드 *2("-" 3ALPHA) ; 영구적으로 예약됨 script = 4ALPHA ; ISO 15924 코드 region = 2ALPHA ; ISO 3166-1 코드 / 3DIGIT ; UN M.49 코드 variant = 5*8alphanum ; 등록된 변형 / (DIGIT 3alphanum) extension = singleton 1*("-" (2*8alphanum)) ; 단일 영숫자 문자 ; "x"는 사적 사용을 위해 예약됨 singleton = DIGIT ; 0 - 9 / %x41-57 ; A - W / %x59-5A ; Y - Z / %x61-77 ; a - w / %x79-7A ; y - z privateuse = "x" 1*("-" (1*8alphanum)) grandfathered = irregular ; 등록된 비중복 태그 / regular ; RFC 3066 시대에 irregular = "en-GB-oed" ; 비정규 태그는 / "i-ami" ; 'langtag' 생성 규칙과 일치하지 않으며 / "i-bnn" ; 그렇지 않았다면 / "i-default" ; 'well-formed'로 간주되지 않았을 것입니다 / "i-enochian" ; 이 태그들은 모두 유효하지만, / "i-hak" ; 대부분은 더 현대적인 / "i-klingon" ; 하위 태그 또는 하위 태그 / "i-lux" ; 조합을 위해 / "i-mingo" ; 폐기되었습니다 Phillips & Davis 현재 최선의 관행 [5페이지]
RFC 5646 언어 태그 2009년 9월 / "i-navajo" / "i-pwn" / "i-tao" / "i-tay" / "i-tsu" / "sgn-BE-FR" / "sgn-BE-NL" / "sgn-CH-DE" regular = "art-lojban" ; 이 태그들은 'langtag' / "cel-gaulish" ; 생성 규칙과 일치하지만, 하위 태그는 / "no-bok" ; 확장 언어 / "no-nyn" ; 또는 변형 하위 태그가 아닙니다. 그 의미는 / "zh-guoyu" ; 등록에 의해 정의되며 / "zh-hakka" ; 이들 모두는 더 현대적인 / "zh-min" ; 하위 태그 또는 하위 태그 시퀀스를 위해 / "zh-min-nan" ; 폐기되었습니다 / "zh-xiang" alphanum = (ALPHA / DIGIT) ; 문자와 숫자 그림 1: 언어 태그 ABNF 언어 태그의 예는 부록 A를 참조하십시오. 모든 하위 태그의 최대 길이는 8자입니다. 언어 태그에는 공백이 허용되지 않습니다. ABNF 생성 규칙 'variant'에는 미묘한 차이가 있습니다. 숫자로 시작하는 변형은 최소 길이가 4자인 반면, 문자로 시작하는 변형은 최소 길이가 5자입니다. [RFC5234]에서는 옥텟을 언급하지만, 이 문서에서 설명하는 언어 태그는 US-ASCII [ISO646] 레퍼토리의 문자 시퀀스입니다. 언어 태그는 관련 US-ASCII 레퍼토리 부분을 포함하는 한 다른 인코딩을 사용하는 문서와 애플리케이션에서도 사용할 수 있습니다. 예를 들어 [Unicode]의 UTF-16LE [RFC2781] 인코딩을 사용하는 XML 문서가 이에 해당합니다. 2.1.1. 언어 태그의 형식 사적 사용 및 확장을 포함하여 언어 태그와 그 하위 태그는 항상 대소문자를 구분하지 않는 것으로 취급해야 합니다. 일부 하위 태그의 대문자 표기에는 관례가 있지만, 이를 의미를 전달하는 것으로 간주해서는 안 됩니다. 따라서 태그 "mn-Cyrl-MN"은 "MN-cYRL-mn" 또는 "mN- cYrL-Mn"(또는 다른 어떠한 조합)과도 구별되지 않으며, 이러한 변형은 Phillips & Davis 현재 최선의 관행 [6페이지]
RFC 5646 언어 태그 2009년 9월 모두 동일한 의미, 즉 몽골에서 사용되는 키릴 문자로 작성된 몽골어를 전달합니다. ABNF 구문 역시 대문자와 소문자를 구별하지 않습니다. 'A'에서 'Z'까지 범위의 대문자 US-ASCII 문자는 항상 동등한 것으로 간주되며, 'a'에서 'z'까지 범위의 해당 US-ASCII 소문자에 직접 매핑됩니다. 따라서 태그 "I-AMI"는 'irregular' 생성 규칙의 값 "i-ami"와 동등한 것으로 간주됩니다. 대소문자 구별은 언어 태그에서 의미를 전달하지 않지만, 언어 태그의 일관된 형식과 표시는 사용자에게 도움이 됩니다. 레지스트리의 하위 태그 형식을 언어 태그에 사용하는 형식으로 권장합니다. 이 형식은 일반적으로 하위 태그의 출처가 되는 여러 ISO 표준의 일반적인 관례에 해당합니다. 이러한 관례에는 다음이 포함됩니다. o [ISO639-1]에서는 언어 코드를 소문자로 작성할 것을 권장합니다 ('mn' 몽골어). o [ISO15924]에서는 문자 체계 코드의 첫 글자를 대문자로 하고 나머지는 소문자로 사용할 것을 권장합니다('Cyrl' 키릴 문자). o [ISO3166-1]에서는 국가 코드를 대문자로 표기할 것을 권장합니다('MN' 몽골). 구현은 다음과 같이 레지스트리에 접근하지 않고도 이 형식을 재현할 수 있습니다. 확장 및 사적 사용 하위 태그를 포함한 모든 하위 태그는 두 가지 예외를 제외하고 소문자를 사용합니다. 즉, 태그의 시작 부분에 나타나지 않으며 singleton 뒤에도 나타나지 않는 두 글자 및 네 글자 하위 태그입니다. 이러한 두 글자 하위 태그는 모두 대문자이고 (예: "en-CA-x-ca" 또는 "sgn-BE-FR"), 네 글자 하위 태그는 첫 글자만 대문자입니다(예: "az-Latn-x-latn"). 참고: 특정 로케일에서 ASCII 문자의 대소문자를 변환할 때 주의해서 처리하지 않으면 때때로 비ASCII 문자 값이 생성됩니다. Unicode Character Database 파일 "SpecialCasing.txt" [SpecialCasing]에는 이러한 문제를 일으키는 것으로 알려진 구체적인 사례가 정의되어 있습니다. 특히 터키어와 아제르바이잔어에서 문자 'i'(U+0069)는 U+0130(LATIN CAPITAL LETTER I WITH DOT ABOVE)으로 대문자화됩니다. 구현자는 하위 태그의 대소문자 변환이 언어 태그에서 허용되지 않는 이 값을 생성하지 않도록 로케일 중립적인 대소문자 변환 연산을 지정하는 것이 좋습니다. 예를 들어 터키어 로케일 규칙을 사용하여 지역 하위 태그 'in'을 대문자로 변환하면 예상되는 'IN' 대신 U+0130 U+004E 시퀀스가 생성됩니다. Phillips & Davis 현재 최선의 관행 [7페이지]
RFC 5646 언어 태그 2009년 9월 2.2. 언어 하위 태그의 출처 및 해석 언어 태그와 그 하위 태그의 이름 공간은 이 문서의 5절에 있는 규칙에 따라 Internet Assigned Numbers Authority(IANA)가 관리합니다. IANA가 유지 관리하는 언어 하위 태그 레지스트리는 유효한 하위 태그의 출처입니다. 이 절에서 참조하는 다른 표준은 해당 레지스트리의 원자료를 제공합니다. 이 문서에서 사용하는 용어는 다음과 같습니다. o "태그"는 "sr-Latn-RS" 또는 "az-Arab-IR"과 같은 완전한 언어 태그를 의미합니다. 이 문서에서 태그의 예는 큰따옴표("en-US")로 묶습니다. o "하위 태그"는 태그 "zh-Hant-CN"의 'zh', 'Hant', 'CN'과 같이 하이픈으로 구분되는 태그의 특정 부분을 의미합니다. 이 문서의 하위 태그 예는 작은따옴표('Hant')로 묶습니다. o "코드"는 외부 표준에서 정의된 값(이 문서에서는 하위 태그로 사용됨)을 의미합니다. 예를 들어 'Hant'는 언어 태그에 사용할 'Hant' 문자 체계 하위 태그를 정의하는 데 사용된 [ISO15924] 문자 체계 코드입니다. 이 문서에서 코드의 예는 작은따옴표 ('en', 'Hant')로 묶습니다. 언어 태그는 각 하위 태그 유형에 고유한 길이 및 내용 제한이 있도록 설계되었습니다. 이러한 제한 덕분에 하위 태그 자체의 내용을 인식하지 못하더라도 하위 태그의 유형을 식별할 수 있습니다. 따라서 기반 표준 또는 IANA 레지스트리의 최신 버전을 참조하지 않고도 태그를 구문 분석하고 처리할 수 있으며, 태그 구문 분석 시 관련 예외 처리도 더 간단해집니다. IANA 레지스트리의 일부 하위 태그는 기반 표준에서 유래하지 않습니다. 이러한 하위 태그는 태그의 특정 위치에만 나타날 수 있습니다. 즉, 기본 언어 하위 태그 또는 변형 하위 태그로만 나타날 수 있습니다. 사적 사용 및 확장 하위 태그의 시퀀스는 반드시 하위 태그 시퀀스의 끝에 나타나야 하며, 이 문서의 다른 곳에서 정의된 하위 태그 사이에 끼워 넣어서는 안 됩니다. 이러한 시퀀스는 다음과 같이 예약된 단일 문자 하위 태그로 시작합니다. o 단일 문자 하위 태그 'x'는 사적 사용 하위 태그 시퀀스를 시작합니다. 모든 사적 사용 하위 태그의 해석은 Phillips & Davis 현재 최선의 관행 [8페이지]
RFC 5646 언어 태그 2009년 9월 오직 사적 합의에 의해 정의되며, 이 절의 규칙이나 이 문서에서 정의하는 어떠한 표준 또는 레지스트리에도 정의되지 않습니다. o 단일 문자 하위 태그 'i'는 "i-default"와 같은 일부 기존 태그에서 사용되며, 항상 첫 번째 위치에 나타나므로 확장과 혼동될 수 없습니다. o 그 밖의 모든 단일 문자 및 단일 숫자 하위 태그는 3.7절에 설명된 표준화된 확장 하위 태그 시퀀스를 시작하기 위해 예약됩니다. 2.2.1. 기본 언어 하위 태그 기본 언어 하위 태그는 언어 태그의 첫 번째 하위 태그이며 다음 두 가지 예외를 제외하고 생략할 수 없습니다. o 단일 문자 하위 태그 'x'가 기본 하위 태그이면 언어 태그가 의미가 전적으로 사적 합의에 의해 정의되는 하위 태그로만 구성됨을 나타냅니다. 예를 들어 태그 "x-fr-CH"에서 사적 합의가 없는 한 하위 태그 'fr'과 'CH'는 프랑스어나 스위스 국가(또는 IANA 레지스트리의 다른 어떠한 값)도 나타내지 않습니다. 4.6절을 참조하십시오. o 단일 문자 하위 태그 'i'는 "i-klingon" 및 "i-bnn"과 같은 일부 기존 태그(2.2.8절 참조)에서 사용됩니다. (다른 기존 태그는 첫 번째 위치에 기본 언어 하위 태그를 가집니다.) 기본 언어 하위 태그에는 다음 규칙이 적용됩니다. 1. 두 문자 기본 언어 하위 태그는 "ISO 639-1:2002, 언어 이름 표현을 위한 코드 -- 제1부: Alpha-2 코드" [ISO639-1] 표준에 있는 할당 또는 이후 ISO 639-1 등록 기관(RA)이나 관련 표준화 관리 기관에서 이루어진 할당에 따라 IANA 레지스트리에 정의되었습니다. 2. IANA 레지스트리의 세 문자 기본 언어 하위 태그는 다음의 추가 ISO 639 부분 중 하나에서 찾을 수 있는 할당 또는 관련 ISO 639 등록 기관이나 관련 표준화 관리 기관에서 이후 이루어진 할당에 따라 정의되었습니다. A. "ISO 639-2:1998 - 언어 이름 표현을 위한 코드 -- 제2부: Alpha-3 코드 - 제1판" [ISO639-2] Phillips & Davis 현재 최선의 관행 [9페이지]
RFC 5646 언어 태그 2009년 9월 B. "ISO 639-3:2007 - 언어 이름 표현을 위한 코드 -- 제3부: 언어를 포괄적으로 다루기 위한 Alpha-3 코드" [ISO639-3] C. "ISO 639-5:2008 - 언어 이름 표현을 위한 코드 -- 제5부: 언어 계통 및 그룹을 위한 Alpha-3 코드" [ISO639-5] 3. 'qaa'에서 'qtz'까지 범위의 하위 태그는 언어 태그에서 사적 사용을 위해 예약되어 있습니다. 이러한 하위 태그는 ISO 639-2가 사적 사용을 위해 예약한 코드에 해당합니다. 이러한 코드는 ('x-' 뒤에 사적 사용 하위 태그를 사용하는 대신) 등록되지 않은 기본 언어 하위 태그에 사용할 수 있습니다. 사적 사용 하위 태그에 관한 자세한 내용은 4.6절을 참조하십시오. 4. 네 문자 언어 하위 태그는 향후 표준화 가능성을 위해 예약됩니다. 5. IANA 레지스트리에서 길이가 5자에서 8자인 모든 언어 하위 태그는 3.5절의 등록 절차를 통해 정의되었으며 기본 언어 하위 태그를 구성하는 데 사용할 수 있습니다. 이러한 등록에 포함될 수 있는 예로 기존 IANA 등록 "i-enochian"이 있습니다. 하위 태그 'enochian'은 (ISO 639가 이 언어를 먼저 등록하지 않는다는 전제에서) IANA 레지스트리에 기본 언어 하위 태그로 등록될 수 있으며, 이에 따라 "enochian-AQ" 및 "enochian- Latn"과 같은 태그가 유효해질 수 있습니다. 이 문서가 작성된 시점에는 이러한 종류의 하위 태그 예가 없었습니다. 향후 이러한 유형의 등록은 권장되지 않습니다. 새로 제안되는 기본 언어를 등록하려는 시도는 반드시 ISO 639 등록 기관에 먼저 이루어져야 합니다. ISO 639 등록 기관에서 거부된 제안은 기본 언어 하위 태그의 기준을 충족할 가능성이 낮으므로 등록될 가능성도 낮습니다. 6. 이 문서를 개정하거나 업데이트하는 경우를 제외하고는 다른 값을 기본 하위 태그에 할당해서는 안 됩니다. 언어에 ISO 639-1 두 문자 코드와 세 문자 코드(ISO 639-2, ISO 639-3 또는 ISO 639-5에서 할당)가 모두 있는 경우에는 ISO 639-1 두 문자 코드만 IANA 레지스트리에 정의됩니다. 언어에 ISO 639-1 두 문자 코드가 없고 해당 언어의 ISO 639-2/T (Terminology) 코드와 ISO 639-2/B(Bibliographic) 코드가 서로 다른 경우에는 Terminology 코드만 IANA 레지스트리에 정의됩니다. 이 문서가 작성된 시점에는 두 종류의 세 문자 코드를 모두 가진 Phillips & Davis 현재 최선의 관행 [10페이지]
RFC 5646 언어 태그 2009년 9월 모든 언어에 두 문자 코드도 할당되어 있었습니다. 향후에는 이러한 종류의 할당이 발생하지 않을 것으로 예상됩니다. 태그의 정규 형식이 불안정해지는 것을 방지하기 위해, 이미 ISO 639-2 또는 ISO 639-3에 세 문자 코드가 포함된 언어에 대해 ISO 639-1에 두 문자 코드가 추가되더라도 해당 두 문자 코드를 등록해서는 안 됩니다. 3.4절을 참조하십시오. 예를 들어 현재 두 문자 코드가 없는 하와이어에 일부 콘텐츠가 'haw'로 태그되어 있다면, 나중에 ISO 639-1이 하와이어에 두 문자 코드를 할당하더라도 해당 태그를 변경할 필요가 없습니다. 이러한 버전 관리 및 하위 태그 선택 문제(RFC 1766에서 RFC 3066으로 전환하는 동안 경험한 문제)를 방지하고, 이 문서에서 정의하는 하위 태그의 정규적 특성을 보장하기 위해 ISO 639 등록 기관 공동 자문 위원회(ISO 639/RA-JAC)는 [iso639.prin]에 다음 문구를 포함했습니다. "ISO 639-1을 동결하는 시점에 이미 ISO 639-2에 있는 언어 코드는 이후 ISO 639-1에 추가해서는 안 됩니다. 이는 시간이 지나도 사용 일관성을 보장하기 위한 것입니다. 인터넷 애플리케이션에서는 해당 언어에 alpha-2 코드가 없는 경우 사용자가 alpha-3 코드를 사용하도록 안내되기 때문입니다." 2.2.2. 확장 언어 하위 태그 확장 언어 하위 태그는 여러 역사적 및 호환성상의 이유로 기존 기본 언어 하위 태그와 밀접하게 식별되거나 이를 사용하여 태그가 지정되는 특별히 선택된 특정 언어를 식별하는 데 사용됩니다. 확장 언어 하위 태그는 언어 태그를 구성할 때 항상 이를 포함하는 기본 언어 하위 태그 (레지스트리의 'Prefix' 필드로 표시됨)와 함께 사용됩니다. 레지스트리에 확장 언어 하위 태그가 있는 모든 언어에는 동일한 기본 언어 하위 태그 레코드도 레지스트리에 있습니다. 언어 태그를 구성할 때는 이 기본 언어 하위 태그를 사용하는 것이 권장됩니다. 확장 언어 하위 태그에는 다음 규칙이 적용됩니다. 1. 확장 언어 하위 태그는 세 문자 하위 태그로만 구성됩니다. 레지스트리에 정의된 모든 확장 언어 하위 태그 레코드는 [ISO639-3]에서 찾을 수 있는 할당에 따라 정의되었습니다. [ISO639-5]에 정의된 것과 같은 언어 집합 및 그룹은 명시적으로 확장 언어 하위 태그에서 제외됩니다. Phillips & Davis 현재 최선의 관행 [11페이지]
RFC 5646 언어 태그 2009년 9월 2. 확장 언어 하위 태그 레코드는 해당 확장 언어 하위 태그에 적합한 하위 태그 또는 하위 태그 시퀀스를 나타내는 'Prefix' 필드를 정확히 하나 포함해야 합니다. 3. 확장 언어 하위 태그 레코드는 'Preferred- Value'를 포함해야 합니다. 'Preferred-Value'와 'Subtag' 필드는 동일해야 합니다. 4. ABNF 생성 규칙 'extlang'은 언어 태그에 최대 세 개의 확장 언어 태그를 허용하지만, 확장 언어 하위 태그의 'Prefix'에는 다른 확장 언어 하위 태그를 포함해서는 안 됩니다. 즉, 언어 태그에서 두 번째와 세 번째 확장 언어 하위 태그 위치는 영구적으로 예약되어 있으며, 해당 위치에 이러한 하위 태그를 포함하는 태그는 현재도 그리고 앞으로도 항상 유효하지 않습니다. 예를 들어 중국어 대언어('zh')는 여러 언어를 포괄합니다. 호환성상의 이유로 이러한 각 언어에는 레지스트리에 기본 언어 하위 태그와 확장 언어 하위 태그가 모두 있습니다. 그중 몇 가지 예로는 간어('gan'), 광둥어('yue'), 관화('cmn')가 있습니다. 각각은 대언어 'zh'(중국어)에 포함됩니다. 따라서 이들의 레지스트리 레코드에는 각각 접두사 "zh"가 있습니다. 이에 따라 간어는 "zh-gan" 또는 "gan"으로 시작하는 태그로, 광둥어는 "yue" 또는 "zh-yue"로 시작하는 태그로, 관화는 "zh-cmn" 또는 "cmn"으로 나타냅니다. 언어 하위 태그 'zh'는 확장 언어 하위 태그 없이도 어떤 특정 종류인지 지정되지 않은 중국어 리소스를 표시하는 데 계속 사용할 수 있지만, 확장 언어 형식 ("zh-gan", "zh-yue", "zh-cmn")보다는 기본 언어 하위 태그 ('gan', 'yue', 'cmn')를 사용하는 것이 권장됩니다. 2.2.3. 문자 체계 하위 태그 문자 체계 하위 태그는 언어나 그 방언의 표기 형식을 구별하는 문자 체계 또는 표기 체계의 변형을 나타내는 데 사용됩니다. 문자 체계 하위 태그에는 다음 규칙이 적용됩니다. 1. 문자 체계 하위 태그는 모든 기본 언어 및 확장 언어 하위 태그 뒤에 와야 하며, 다른 모든 유형의 하위 태그보다 앞에 와야 합니다. 2. 문자 체계 하위 태그는 네 글자로 구성되며 [ISO15924] ("정보 및 문서화 -- 문자 체계 이름 표현을 위한 코드")에서 찾을 수 있는 할당 또는 이후 ISO 15924 등록 기관이나 관련 표준화 관리 기관에서 할당한 값에 따라 정의되었습니다. ISO 15924가 할당한 코드만 등록 대상으로 고려됩니다. Phillips & Davis 현재 최선의 관행 [12페이지]
RFC 5646 언어 태그 2009년 9월 3. 문자 체계 하위 태그 'Qaaa'부터 'Qabx'까지는 언어 태그에서 사적 사용을 위해 예약됩니다. 이러한 하위 태그는 ISO 15924에서 사적 사용을 위해 예약된 코드에 해당합니다. 이러한 코드는 등록되지 않은 문자 체계 값에 사용할 수 있습니다. 사적 사용 하위 태그에 관한 자세한 내용은 4.6절을 참조하십시오. 4. 언어 태그에는 문자 체계 하위 태그가 최대 하나만 있어야 하며, 문자 체계 하위 태그가 태그에 구별되는 가치를 추가하지 않거나 하위 태그 레지스트리의 기본 또는 확장 언어 하위 태그 레코드에 해당 문자 체계 하위 태그를 나열하는 'Suppress-Script' 필드가 포함된 경우에는 문자 체계 하위 태그를 생략하는 것이 좋습니다. 예를 들어 "sr-Latn"은 라틴 문자로 작성된 세르비아어를 나타냅니다. 2.2.4. 지역 하위 태그 지역 하위 태그는 특정 국가, 영토 또는 지역과 관련되거나 이에 적합한 언어적 변형을 나타내는 데 사용됩니다. 일반적으로 지역 하위 태그는 지역 방언이나 용법 또는 지역별 철자 관례와 같은 변형을 나타내는 데 사용됩니다. 또한 특정 지역 전역에서 사용하기에 적합한 방식으로 콘텐츠가 표현되었음을 나타내는 데에도 사용할 수 있습니다. 예를 들어 라틴 아메리카 전역에서 유용하도록 조정된 스페인어 콘텐츠가 이에 해당합니다. 지역 하위 태그에는 다음 규칙이 적용됩니다. 1. 지역 하위 태그는 모든 기본 언어, 확장 언어 또는 문자 체계 하위 태그 뒤에 와야 하며, 다른 모든 유형의 하위 태그보다 앞에 와야 합니다. 2. 두 글자 지역 하위 태그는 [ISO3166-1]("국가 및 그 하위 구역 이름 표현을 위한 코드 -- 제1부: 국가 코드")에서 찾을 수 있는 할당에 따라 alpha-2 국가 코드 목록을 사용하거나 이후 ISO 3166-1 유지 관리 기관 또는 관련 표준화 관리 기관에서 이루어진 할당을 사용하여 정의되었습니다. 또한 ISO 3166-1에서 "할당됨"이 아니라 "예외적으로 예약됨"으로 지정된 코드도 레지스트리에 정의되었습니다. 단, 할당된 코드 'GB'와 정확히 동의어인 'UK'는 예외입니다. 3. 지역 하위 태그 'AA', 'QM'-'QZ', 'XA'-'XZ', 'ZZ'는 언어 태그에서 사적 사용을 위해 예약됩니다. 이러한 하위 태그는 ISO 3166에서 사적 사용을 위해 예약된 코드에 해당합니다. 이러한 코드는 (사적 사용 하위 태그 시퀀스를 사용하는 대신) 사적 사용 지역 하위 태그에 사용할 수 있습니다. 사적 사용 하위 태그에 관한 자세한 내용은 4.6절을 참조하십시오. Phillips & Davis 현재 최선의 관행 [13페이지]
RFC 5646 언어 태그 2009년 9월 4. 세 문자 지역 하위 태그는 숫자 문자로만 구성되며 UN 통계용 표준 국가 또는 지역 코드 [UN_M.49]에서 찾을 수 있는 할당이나 이후 관련 표준 기관에서 이루어진 할당에 따라 정의되었습니다. 모든 UN M.49 코드가 IANA 레지스트리에 정의되어 있는 것은 아닙니다. 다음 규칙은 어떤 코드를 유효한 하위 태그로 레지스트리에 입력하는지를 정의합니다. A. '대지리적(대륙)' 지역 또는 하위 지역에 할당된 UN 숫자 코드는 반드시 레지스트리에 등록해야 합니다. 이러한 코드는 할당된 ISO 3166-1 alpha-2 코드와 연결되지 않으며, 일반적으로 둘 이상의 국가, 주, 지방 또는 영토를 포함하는 초국가적 지역을 나타냅니다. B. '경제 그룹' 또는 '기타 그룹'에 대한 UN 숫자 코드는 IANA 레지스트리에 등록해서는 안 되며 언어 태그를 구성하는 데 사용해서도 안 됩니다. C. ISO 3166-1이 이전에 한 국가 또는 지역에 사용되던 코드를 다른 국가 또는 지역에 재할당하고 해당 코드가 이미 레지스트리에 존재하는 경우, 해당 국가 또는 지역의 UN 숫자 코드는 3.4절에 설명된 대로 반드시 레지스트리에 등록해야 하며, 정의된 국가 또는 지역을 나타내는 언어 태그를 구성할 때 (재활용된 ISO 3166-1 코드 대신) 반드시 사용해야 합니다. D. 레지스트리에 관련 ISO 3166-1 alpha-2 코드가 있는 국가 또는 지역의 UN 숫자 코드는 레지스트리에 입력해서는 안 되며, 언어 태그를 구성하는 데 사용해서도 안 됩니다. 레지스트리의 ISO 3166 기반 하위 태그는 실제로 해당 UN M.49 코드와 연결되어 있어야 한다는 점에 유의하십시오. E. 역사적인 이유로, 이 문서가 채택될 당시 등록되지 않았고 당시 대응하는 ISO 3166-1 코드가 없었던 UN 숫자 코드 830(Channel Islands)은 동일한 의미를 가진 ISO 3166-1 코드가 이전에 등록되지 않았다는 조건에서 3.5절에 설명된 절차를 통해 IANA 레지스트리에 입력할 수 있습니다. F. 관련 ISO 3166-1 alpha-2 코드가 없는 국가 또는 지역의 그 밖의 모든 UN 숫자 코드는 레지스트리에 입력해서는 안 되며, 언어 태그를 구성하는 데 사용해서도 안 됩니다. 이러한 코드에 관한 자세한 내용은 3.4절을 참조하십시오. Phillips & Davis 현재 최선의 관행 [14페이지]
RFC 5646 언어 태그 2009년 9월 5. UN 문서의 부록 X에 있는 영숫자 코드는 레지스트리에 입력해서는 안 되며 언어 태그를 구성하는 데 사용해서도 안 됩니다. (이 문서가 작성된 시점에는 이러한 값이 ISO 3166-1 alpha-2 코드와 일치했습니다.) 6. 언어 태그에는 지역 하위 태그가 최대 하나만 있어야 하며, 지역 하위 태그가 태그에 구별되는 가치를 추가하지 않는 경우처럼 지역 하위 태그를 생략할 수 있습니다. 예를 들면 다음과 같습니다. "de-AT"는 오스트리아('AT')에서 사용되는 독일어('de')를 나타냅니다. "sr-Latn-RS"는 세르비아('RS')에서 사용되는 라틴 문자 ('Latn')로 작성된 세르비아어('sr')를 나타냅니다. "es-419"는 UN에서 정의한 라틴 아메리카 및 카리브 지역('419')에 적합한 스페인어('es')를 나타냅니다. 2.2.5. 변형 하위 태그 변형 하위 태그는 사용 가능한 다른 하위 태그로는 다루지 않는, 언어나 그 방언을 정의하는 추가적이고 널리 인정된 변형을 나타내는 데 사용됩니다. 변형 하위 태그에는 다음 규칙이 적용됩니다. 1. 변형 하위 태그는 모든 기본 언어, 확장 언어, 문자 체계 또는 지역 하위 태그 뒤에 와야 하며, 모든 확장 또는 사적 사용 하위 태그 시퀀스보다 앞에 와야 합니다. 2. 변형 하위 태그는 전체적으로 특정 외부 표준과 연결되어 있지 않습니다. 레지스트리의 변형 하위 태그 의미는 3.5절에 정의된 등록 절차 중에 정의됩니다. 특정 변형 하위 태그가 어떤 외부 표준과 연결될 수 있다는 점에 유의하십시오. 그러나 표준과의 연결은 등록에 필수적이지 않습니다. 3. 언어 태그를 구성하는 데 둘 이상의 변형을 사용할 수 있습니다. 4. 변형 하위 태그는 언어 태그를 구성하는 데 사용하기 전에 이 문서의 3.5절 규칙에 따라 IANA에 등록해야 합니다. 변형을 다른 유형의 하위 태그와 구별하기 위해 등록은 다음의 길이 및 내용 제한을 충족해야 합니다. 1. 문자(a-z, A-Z)로 시작하는 변형 하위 태그는 길이가 최소 5자여야 합니다. Phillips & Davis 현재 최선의 관행 [15페이지]
RFC 5646 언어 태그 2009년 9월 2. 숫자(0-9)로 시작하는 변형 하위 태그는 길이가 최소 4자여야 합니다. 5. 동일한 변형 하위 태그를 하나의 언어 태그 안에서 두 번 이상 사용해서는 안 됩니다. * 예를 들어 태그 "de-DE-1901-1901"은 유효하지 않습니다. 언어 하위 태그 레지스트리의 변형 하위 태그 레코드는 하나 이상의 'Prefix'(3.1.8절) 필드를 포함할 수 있습니다. 각 'Prefix'는 변형을 사용할 때 (필요에 따라 다른 하위 태그와 함께) 언어 태그를 구성하기에 적합한 하위 태그 시퀀스를 나타냅니다. 동일한 접두사를 공유하는 대부분의 변형은 상호 배타적입니다. 예를 들어 독일어 철자법 변형 '1996'과 '1901'은 서로 다른 철자법 개혁의 연도를 나타내므로 동일한 태그에서 함께 사용하지 않는 것이 좋습니다. 다른 변형과 의미 있게 함께 사용할 수 있는 변형은 레지스트리 레코드의 'Prefix' 필드에 해당 다른 변형을 나열하는 것이 좋습니다. 예를 들어 '1996'과 함께 사용하는 것이 의미 있는 또 다른 독일어 변형 'example'이 생성된다면 'example'에는 "de"와 "de-1996"이라는 두 개의 'Prefix' 필드를 포함하는 것이 좋습니다. 예를 들면 다음과 같습니다. "sl-nedis"는 슬로베니아어의 Natisone 또는 Nadiza 방언을 나타냅니다. "de-CH-1996"은 스위스에서 사용되며 서기 1996년에 시작된 철자법 개혁을 사용하여 작성된 독일어를 나타냅니다. 2.2.6. 확장 하위 태그 확장은 다양한 애플리케이션에서 사용할 수 있도록 언어 태그를 확장하는 메커니즘을 제공합니다. 이는 일반적으로 언어나 언어 태그와 관련하여 사용되지만 언어 식별 자체의 일부는 아닌 정보를 식별하기 위한 것입니다. 3.7절을 참조하십시오. 확장에는 다음 규칙이 적용됩니다. 1. 확장은 최소한 기본 언어 하위 태그 뒤에 와야 합니다. 즉, 언어 태그는 확장으로 시작할 수 없습니다. 확장은 언어 태그를 확장하는 것이며, 이를 재정의하거나 대체하지 않습니다. 예를 들어 "a-value"는 올바른 형식의 언어 태그가 아니지만 "de-a-value"는 올바른 형식입니다. 확장은 전적으로 사적 사용인 태그(즉, "x-"로 시작하는 태그)에는 사용할 수 없다는 점에 유의하십시오. Phillips & Davis 현재 최선의 관행 [16페이지]
RFC 5646 언어 태그 2009년 9월 2. 확장 하위 태그는 단일 문자 하위 태그("singleton"이라고 함)를 통해 이 문서에 정의된 다른 하위 태그와 구분됩니다. singleton은 3.7절에 설명된 메커니즘을 통해 등록 기관에 할당된 것이어야 하며, 사적 사용 하위 태그 시퀀스를 위해 예약된 문자 'x'여서는 안 됩니다. 3. 각 singleton 하위 태그는 각 태그에서 최대 한 번만 나타나야 합니다(사적 사용 하위 태그로 나타나는 경우 제외). 즉, singleton 하위 태그를 반복해서는 안 됩니다. 예를 들어 태그 "en-a-bbb-a-ccc"는 하위 태그 'a'가 두 번 나타나므로 유효하지 않습니다. 태그 "en-a-bbb-x-a-ccc"는 singleton 'a'의 두 번째 출현이 사적 사용 시퀀스 안에 있으므로 유효하다는 점에 유의하십시오. 4. 확장 하위 태그는 해당 singleton 접두사를 정의하는 문서에서 정한 모든 요구 사항과 유지 관리 기관에서 제공하는 모든 요구 사항을 충족해야 합니다. 이러한 하위 태그의 레지스트리가 없을 수도 있으며, 검증 처리기는 확장을 검증할 필요가 없다는 점에 유의하십시오. 5. 각 확장 하위 태그의 길이는 2자에서 8자여야 하며 문자 또는 숫자로만 구성되어야 하고, 각 하위 태그는 하나의 '-'로 구분되어야 합니다. 확장에서는 (다른 모든 언어 하위 태그와 마찬가지로) 대소문자 구별이 무시되며, 이 유형의 정규화된 하위 태그는 소문자로 작성할 것으로 예상됩니다. 6. 각 singleton 뒤에는 최소 하나의 확장 하위 태그가 와야 합니다. 예를 들어 태그 "tlh-a-b-foo"는 첫 번째 singleton 'a' 바로 뒤에 다른 singleton 'b'가 오므로 유효하지 않습니다. 7. 확장 하위 태그는 태그 안의 모든 기본 언어, 확장 언어, 문자 체계, 지역 및 변형 하위 태그 뒤에 와야 하며, 모든 사적 사용 하위 태그 시퀀스보다 앞에 와야 합니다. 8. singleton 뒤에서 다른 singleton이 나오기 전까지의 모든 하위 태그는 확장의 일부입니다. 예: 태그 "fr-a-Latn"에서 하위 태그 'Latn'은 IANA 언어 하위 태그 레지스트리에 정의된 문자 체계 하위 태그 'Latn'을 나타내지 않습니다. 그 의미는 확장 'a'에 의해 정의됩니다. 9. 하나의 태그에 둘 이상의 확장이 나타나는 경우, 다양한 확장 시퀀스를 대소문자를 구분하지 않는 ASCII 순서로 정렬하여 4.5절에 설명된 대로 태그를 정규화하는 것이 좋습니다. 예를 들어 singleton 'r'에 대한 확장이 정의되고 여기에 표시된 하위 태그가 정의되었다면 다음 태그가 유효한 예가 됩니다. "en-Latn-GB-boont-r-extended-sequence-x-private". Phillips & Davis 현재 최선의 관행 [17페이지]
RFC 5646 언어 태그 2009년 9월 2.2.7. 사적 사용 하위 태그 사적 사용 하위 태그는 사적 합의에 따라 특정 상황에서 중요한 언어상의 구별을 나타내는 데 사용됩니다. 사적 사용 하위 태그에는 다음 규칙이 적용됩니다. 1. 사적 사용 하위 태그는 예약된 단일 문자 하위 태그 'x'를 통해 이 문서에서 정의된 다른 하위 태그와 구분됩니다. 2. 사적 사용 하위 태그는 모든 하위 태그에 대해 ABNF에 정의된 형식 및 내용 제한을 준수해야 합니다. 즉, 문자와 숫자로만 구성되어야 하며 길이가 8자를 초과해서는 안 됩니다. 3. 사적 사용 하위 태그는 태그의 모든 기본 언어, 확장 언어, 문자 체계, 지역, 변형 및 확장 하위 태그 뒤에 와야 합니다. 이를 달리 말하면 singleton 'x' 뒤에 오는 모든 하위 태그는 사적 사용으로 간주해야 합니다. 예: 태그 "en-x-US"의 하위 태그 'US'는 사적 사용 하위 태그입니다. 4. 태그는 전적으로 사적 사용 하위 태그로 구성될 수 있습니다. 5. 사적 사용 하위 태그에는 정의된 출처가 없습니다. 사적 사용 하위 태그는 오직 사적 합의에 따라 사용됩니다. 6. 대안이 존재하거나 일반적인 정보 교환에 사용할 경우 사적 사용 하위 태그는 권장되지 않습니다. 사적 사용 하위 태그 선택에 관한 자세한 내용은 4.6절을 참조하십시오. 예를 들어 한 학자 그룹이 중세 그리스어로 된 일부 문헌을 연구한다고 가정하겠습니다. 이들은 문헌에 나타나는 서로 다른 문체를 식별하기 위해 어떤 사적 사용 하위 태그 집합을 사용하기로 합의할 수 있습니다. 예를 들어 "일반적인" 문체의 문서에는 'el-x-koine'을 사용하고, 아티카 문체를 모방한 다른 문서에는 'el-x-attic'을 사용할 수 있습니다. 이러한 하위 태그는 외부 프로세스나 시스템에서는 인식되지 않지만, 해당 그룹의 사람들이 연구를 위해 여러 문헌을 분류하는 데 유용할 수 있습니다. 레지스트리에는 ISO 639, ISO 15924 또는 ISO 3166에서 사적 사용을 위해 예약한 코드에서 파생된 하위 태그도 있습니다. 이를 하위 태그 'x' 뒤에 오는 사적 사용 하위 태그 시퀀스와 혼동하지 마십시오. 4.6절을 참조하십시오. 2.2.8. 기존 및 중복 등록 RFC 4646 이전에는 전체 언어 태그가 RFC 1766 및/또는 RFC 3066의 규칙에 따라 등록되었습니다. 이렇게 등록된 모든 태그는 언어 태그로서 계속 유효합니다. Phillips & Davis 현재 최선의 관행 [18페이지]
RFC 5646 언어 태그 2009년 9월 이렇게 등록된 태그 중 상당수는 RFC 4646 또는 이 문서의 등장으로 중복되었습니다. 중복 태그란 각각의 하위 태그가 동일한 의미로 레지스트리에 나타나는 기존 등록입니다. 예를 들어 태그 "zh-Hant" (번체 중국어)는 이제 하위 태그 'zh'(중국어)와 'Hant'(한자 문자 체계의 번체 변형)로 구성할 수 있습니다. 이러한 중복 태그는 주로 역사적 참고를 위해 'redundant' 유형의 레코드로 레지스트리에 유지됩니다. 이전에 등록된 나머지 태그는 "기존" 태그입니다. 이러한 태그는 'regular'와 'irregular'이라는 두 그룹으로 분류됩니다. 그림 1의 'langtag' 생성 규칙과 (겉보기에는) 일치하는 기존 태그는 'regular' 기존 태그로 간주됩니다. 이러한 태그에는 개별적으로 레지스트리에 나타나지 않거나, 나타나더라도 다른 의미를 갖는 하나 이상의 하위 태그가 포함됩니다. 각 태그는 전체적으로 하나의 언어 또는 언어 집합을 나타냅니다. ABNF의 'langtag' 생성 규칙과 일치하지 않아 그렇지 않으면 유효하지 않은 기존 태그는 'irregular' 기존 태그로 간주됩니다. "en-GB"의 변형인 "en-GB-oed"를 제외하면 각 태그는 전체적으로 하나의 언어를 나타냅니다. 많은 기존 태그는 이후 새로운 하위 태그가 추가되면서 대체되었습니다. 대체된 각 레코드에는 해당 값을 나타내는 언어 태그를 구성하는 데 사용해야 하는 'Preferred-Value' 필드가 포함됩니다. 예를 들어 태그 "art-lojban"은 기본 언어 하위 태그 'jbo'로 대체되었습니다. 2.2.9. 적합성 클래스 구현에서는 이 문서에 설명된 규칙 및 관행과 관련하여 자신의 기능을 설명해야 하는 경우가 있습니다. 태그는 여러 방식으로 확인하거나 검증할 수 있지만, 여기에서는 두 가지 특정 태그 적합성 클래스를 공식적으로 정의합니다. 태그가 ABNF(2.1절)를 준수하면 "올바른 형식"으로 간주됩니다. 언어 태그는 구문 측면에서는 올바른 형식이지만 내용 측면에서는 유효하지 않을 수 있습니다. 그러나 언어 태그와 관련된 많은 작업은 하위 태그의 의미나 유효성에 대해 아무것도 알지 못해도 잘 작동합니다. 다음 조건을 충족하면 태그는 "유효"한 것으로 간주됩니다. o 태그가 올바른 형식입니다. Phillips & Davis 현재 최선의 관행 [19페이지]
RFC 5646 언어 태그 2009년 9월 o 태그가 기존 태그 목록에 있거나, 태그의 모든 기본 언어, 확장 언어, 문자 체계, 지역 및 변형 하위 태그가 해당 레지스트리 날짜 기준으로 IANA 언어 하위 태그 레지스트리에 나타납니다. o 중복된 변형 하위 태그가 없습니다. o 중복된 singleton(확장) 하위 태그가 없습니다. 태그의 유효성은 태그를 검증하는 데 사용한 레지스트리의 날짜에 따라 달라진다는 점에 유의하십시오. 더 최신 레지스트리 사본에는 이전 버전에는 없는 하위 태그가 포함될 수 있습니다. 태그가 위의 "유효" 기준을 충족하고 다음 조건도 충족하면 특정 확장(3.7절)에 대해 (특정 버전, 개정판 및 날짜를 기준으로) 유효한 것으로 간주됩니다. 태그의 확장 부분에서 사용되는 각 하위 태그가 해당 확장에 따라 유효합니다. 이전 규격이나 언어 태그 구현에서는 때때로 [RFC3066]을 참조합니다. 해당 문서에서는 더 넓은 범위의 태그가 올바른 형식으로 간주되었습니다. RFC 3066에서 사용하기에 유효했던 모든 태그는 이 문서의 구문에서도 올바른 형식이며 유효합니다. 이전 정의에서는 올바른 형식이었지만 이제는 그렇지 않은 것은 유효하지 않거나 허용되지 않는 태그뿐입니다. RFC 3066의 언어 태그 구문은 다음과 같았습니다. obs-language-tag = primary-subtag *( "-" subtag ) primary-subtag = 1*8ALPHA subtag = 1*8(ALPHA / DIGIT) 그림 2: RFC 3066 언어 태그 구문 사적 사용을 위해 지정된 하위 태그와 'x' 하위 태그로 시작되는 사적 사용 시퀀스는 할당된 하위 태그가 없고 등록이 적절한 선택이 아닌 경우에 사용할 수 있습니다. 예를 들어 달리 정의되지 않은 지역을 나타내기 위해 사적 사용 ISO 3166-1 코드 범위 중 하나인 'QQ'를 사용하는 "no-QQ"와 같은 태그를 사용할 수 있습니다. 사용자는 사적 사용 시퀀스(예: 태그 "en-x-personal"의 하위 태그 'personal') 외부에서는 레지스트리에 나타나지 않는 하위 태그를 사용하는 언어 태그를 할당해서는 안 됩니다. 이러한 태그는 유효하지 않을 뿐만 아니라 향후 이루어질 수 있는 할당 또는 등록과 충돌할 위험도 있습니다. 특히 유의하십시오. 이 문서에 나타나는 'Language-Tag' 생성 규칙은 기능적으로 [RFC4646]의 생성 규칙과 동일하지만, Phillips & Davis 현재 최선의 관행 [20페이지]
RFC 5646 언어 태그 2009년 9월 이전의 'grandfathered' 생성 규칙에서 발생하는 특정 올바른 형식 오류를 방지하도록 변경되었습니다. 3. 레지스트리 형식 및 유지 관리 IANA 언어 하위 태그 레지스트리("레지스트리")에는 언어 태그에서 유효한 모든 하위 태그의 포괄적인 목록이 포함되어 있습니다. 이를 통해 구현자는 언어 태그를 간단하고 신뢰할 수 있는 방식으로 검증할 수 있습니다. 레지스트리는 확장 하위 태그를 제외하고 이 문서 또는 그 개정판이나 후속 문서의 규정에 따라 언어 태그에 나타나는 모든 하위 태그를 검증할 수 있도록 유지 관리됩니다. 또한 여러 하위 태그의 의미는 모호하지 않으며 시간이 지나도 안정적으로 유지됩니다. (물론 사적 사용 하위 태그의 의미는 레지스트리에 의해 정의되지 않습니다.) 이 절에서는 레지스트리와 관련 유지 관리 및 업데이트 절차뿐 아니라 언어 태그 확장을 위한 레지스트리(3.7절)도 정의합니다. 3.1. IANA 언어 하위 태그 레지스트리의 형식 IANA 언어 하위 태그 레지스트리는 이 절에서 설명하는 형식의 기계 판독 가능 파일이며, 여기에 3.5절에 설명된 절차에 따라 승인된 등록 양식의 사본이 추가됩니다. RFC 3066에서 가져온 기존 및 중복 태그의 기존 등록 양식은 폐기된 RFC 3066 레지스트리의 일부로 유지되어 왔습니다. [RFC4645] 또는 [RFC5645]에 의해 레지스트리에 추가된 하위 태그에는 별도의 등록 양식이 없습니다(따라서 이러한 추가 항목의 양식은 보관되지 않습니다). 3.1.1. 파일 형식 레지스트리는 [Unicode] 텍스트 파일이며 "record-jar" ([record-jar]에 설명됨)에 기반한 형식의 일련의 레코드로 구성됩니다. 각 레코드는 다시 여러 하위 태그와 태그를 설명하는 일련의 필드로 구성됩니다. 실제 레지스트리 파일은 UTF-8 [RFC3629] 문자 인코딩을 사용하여 인코딩됩니다. 각 필드는 하나의 논리적인 문자 줄로 간주할 수 있습니다. 각 필드에는 "field-name"과 "field-body"가 포함됩니다. 이들은 "field-separator"로 구분됩니다. field-separator는 COLON 문자(U+003A)와 그 주변의 공백입니다. 각 필드는 줄바꿈 시퀀스 CRLF로 끝납니다. 각 필드의 텍스트는 반드시 유니코드 정규화 형식 C(NFC)여야 합니다. Phillips & Davis 현재 최선의 관행 [21페이지]
RFC 5646 언어 태그 2009년 9월 필드의 모음은 하나의 "레코드"를 구성합니다. 레코드는 오직 "%%"(U+0025 U+0025) 시퀀스만 포함하는 줄로 구분됩니다. 필드는 논리적으로 한 줄의 텍스트이지만 파일 형식의 각 텍스트 줄은 길이가 72바이트로 제한됩니다. 이를 수용하기 위해 field-body를 여러 줄 표현으로 나눌 수 있으며, 이를 "folding"이라고 합니다. Folding은 일반적인 줄 바꿈 관례에 따라 수행됩니다. 일반적으로 공백 경계에서 이루어지지만, 언어가 단어 사이에 공백을 사용하지 않는 경우처럼 값에 공백이 포함되지 않으면 다른 문자 사이에서도 이루어질 수 있습니다. 어떤 경우에도 다중 바이트 UTF-8 시퀀스 내부나 결합 문자 시퀀스의 중간에서 줄을 나누어서는 안 됩니다. 자세한 내용은 [UAX14]를 참조하십시오. 파일 형식은 유니코드 문자 집합을 사용하고 파일 자체는 UTF-8 인코딩을 사용하여 인코딩되지만, 특정 필드의 설명에서 달리 명시하지 않는 한(3.1.2절) 필드는 US-ASCII [ISO646] 레퍼토리의 인쇄 가능한 문자로 제한됩니다. 레지스트리의 형식은 다음 ABNF [RFC5234]로 설명됩니다. 문자 번호(코드 포인트)는 유니코드에서 가져오며 ABNF 생성 규칙의 터미널은 바이트가 아니라 문자를 기준으로 합니다. registry = record *("%%" CRLF record) record = 1*field field = ( field-name field-sep field-body CRLF ) field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] field-sep = *SP ":" *SP field-body = *([[*SP CRLF] 1*SP] 1*CHARS) CHARS = (%x21-10FFFF) ; 유니코드 코드 포인트 그림 3: 레지스트리 형식 ABNF field-body의 '..'(U+002E U+002E) 시퀀스는 값의 범위를 나타냅니다. 이러한 범위는 명시적으로 언급된 값을 포함하여 해당 범위 안에서 알파벳 또는 숫자 순서에 있는 동일한 길이의 모든 하위 태그를 나타냅니다. 예를 들어 'a..c'는 'a', 'b', 'c' 값을 나타내고, '11..13'은 '11', '12', '13' 값을 나타냅니다. field-body에 날짜 값이 포함된 모든 필드는 [RFC3339]에 규정된 "full-date" 형식을 사용합니다. 예를 들어 "2004-06-28"은 그레고리력의 2004년 6월 28일을 나타냅니다. Phillips & Davis 현재 최선의 관행 [22페이지]
RFC 5646 언어 태그 2009년 9월 3.1.2. 레코드 및 필드 정의 레지스트리에는 "File-Date", "Subtag", "Tag"의 세 가지 유형의 레코드가 있습니다. 레지스트리의 첫 번째 레코드는 항상 "File-Date" 레코드입니다. 이 레코드는 파일에서 한 번만 나타나며 field-name이 "File-Date"인 단일 필드를 포함합니다. 이 레코드의 field-body에는 날짜 (5.1절 참조)가 포함되어 있어 서로 다른 레지스트리 버전을 쉽게 식별할 수 있습니다. File-Date: 2004-06-28 %% 그림 4: File-Date 레코드의 예 이후의 레코드에는 여러 필드가 포함되며 하위 태그 또는 태그에 관한 정보를 나타냅니다. 두 유형의 레코드는 구조가 동일하지만, "Subtag" 레코드는 field-name이 "Subtag"인 필드를 포함하고, 예상할 수 있듯이 "Tag" 레코드는 field-name이 "Tag"인 필드를 포함합니다. 'Description', 'Comments', 'Prefix' 필드를 제외하고 field-name은 한 레코드에서 두 번 이상 나타나서는 안 됩니다. 각 레코드에는 다음 필드가 각각 최소 하나 이상 포함되어야 합니다. o 'Type' * Type의 field-body는 다음 문자열 중 하나로 구성되어야 합니다. "language", "extlang", "script", "region", "variant", "grandfathered", "redundant". 이는 태그 또는 하위 태그의 유형을 나타냅니다. o 'Subtag' 또는 'Tag' * Subtag의 field-body에는 정의되는 하위 태그가 포함됩니다. 이 필드는 'Type'이 "language", "extlang", "script", "region" 또는 "variant" 값 중 하나인 모든 레코드에 반드시 나타나야 합니다. * Tag의 field-body에는 완전한 언어 태그가 포함됩니다. 이 필드는 'Type'이 "grandfathered" 또는 "redundant" 값 중 하나인 모든 레코드에 반드시 나타나야 합니다. 'Type'이 "grandfathered"인 경우 'Tag' field-body는 2.1절의 'regular' 또는 'irregular' 생성 규칙에 나열된 태그 중 하나입니다. Phillips & Davis 현재 최선의 관행 [23페이지]
RFC 5646 언어 태그 2009년 9월 o 'Description' * Description의 field-body에는 하위 태그 또는 태그에 대한 비규범적 설명이 포함됩니다. o 'Added' * Added의 field-body에는 레코드가 등록된 날짜가 포함되며, 기존 또는 중복 태그의 경우에는 해당 태그가 [RFC1766] 또는 [RFC3066]의 규칙에 따라 등록된 날짜가 포함됩니다. 각 레코드에는 다음 필드가 포함될 수도 있습니다. o 'Deprecated' * Deprecated의 field-body에는 레코드가 폐기된 날짜가 포함됩니다. 경우에 따라 이 값은 같은 레코드의 'Added' 필드보다 이전일 수 있습니다. 즉, 폐기 날짜가 레코드가 레지스트리에 추가된 날짜보다 앞설 수 있습니다. o 'Preferred-Value' * Preferred-Value의 field-body에는 이 레코드의 값에서 그 대신 사용하는 것이 선호되는 현대적 동등 값으로의 정규 매핑이 포함됩니다. 'Type' 필드의 값에 따라 이 값은 서로 다른 형식을 취할 수 있습니다. + 'language' 유형의 필드에서 'Preferred-Value'는 언어 태그를 구성할 때 선호되는 기본 언어 하위 태그를 포함합니다. + 'script', 'region' 또는 'variant' 유형의 필드에서 'Preferred-Value'는 언어 태그를 구성할 때 선호되는 동일한 유형의 하위 태그를 포함합니다. + 'extlang', 'grandfathered' 또는 'redundant' 유형의 필드에서 'Preferred-Value'는 언어 태그를 구성할 때 선호되는 "확장 언어 범위" [RFC4647]를 포함합니다. 즉, 선호되는 언어 태그에는 'Preferred-Value'에 나타나는 각 하위 태그가 순서대로 포함됩니다. 이 문서의 다른 곳에 설명된 대로 언어 태그에 추가 필드를 포함할 수도 있습니다. 예를 들어 기존 태그 "zh-min- nan"(민난어)의 대체 값은 "nan"이며, 이를 Phillips & Davis 현재 최선의 관행 [24페이지]
RFC 5646 언어 태그 2009년 9월 "nan-Hant" 또는 "nan-TW"와 같은 태그의 기반으로 사용할 수 있습니다("zh-nan-Hant" 또는 "zh- nan-TW"와 같은 확장 언어 하위 태그 형식도 사용할 수 있다는 점에 유의하십시오). o 'Prefix' * Prefix의 field-body에는 이 레코드의 하위 태그에 가능한 접두사 중 하나로 권장되는 유효한 언어 태그가 포함됩니다. 이 필드는 'Type' field-body가 'extlang' 또는 'variant'인 레코드에 나타날 수 있습니다(그 밖의 레코드 유형에는 나타나서는 안 됩니다). o 'Suppress-Script' * Suppress-Script의 field-body에는 관련 기본 또는 확장 언어 하위 태그와 함께 언어 태그를 구성하는 데 사용하지 않는 것이 좋은 문자 체계 하위 태그가 포함됩니다. 이 필드는 'Type' field-body가 'language' 또는 'extlang'인 레코드에만 나타나야 합니다. 4.1절을 참조하십시오. o 'Macrolanguage' * Macrolanguage의 field-body에는 ISO 639가 이 언어 하위 태그를 포괄하는 "대언어"로 정의한 기본 언어 하위 태그가 포함됩니다. 이 필드는 'Type' field-body가 'language' 또는 'extlang'인 레코드에만 나타나야 합니다. o 'Scope' * Scope의 field-body에는 ISO 639에 따른 언어 코드의 유형을 나타내는 기본 또는 확장 언어 하위 태그에 관한 정보가 포함됩니다. 이 필드에서 허용되는 값은 "macrolanguage", "collection", "special", "private-use"입니다. 이 필드는 'Type' field-body가 'language' 또는 'extlang'인 레코드에만 나타납니다. 이 필드가 생략되면 해당 언어는 개별 언어입니다. o 'Comments' * Comments의 field-body에는 레지스트리를 이해하고 해당 하위 태그 또는 태그를 사용하여 언어 태그를 구현하는 데 적절하다고 판단되는 하위 태그에 관한 추가 정보가 포함됩니다. 이 문서의 향후 버전에서는 레지스트리에 추가 필드를 추가할 수 있습니다. 구현은 이 문서에 정의되지 않은 레지스트리의 필드를 무시하는 것이 좋습니다. Phillips & Davis 현재 최선의 관행 [25페이지]
RFC 5646 언어 태그 2009년 9월 3.1.3. Type 필드 'Type' 필드에는 해당 필드가 나타나는 레코드 유형을 식별하는 문자열이 포함됩니다. 'Type' field-body의 값은 "language" (2.2.1절), "extlang"(2.2.2절), "script"(2.2.3절), "region"(2.2.4절), "variant"(2.2.5절), "grandfathered" 또는 "redundant"(2.2.8절)입니다. 3.1.4. Subtag 및 Tag 필드 'Subtag' 필드에는 레코드에서 정의하는 하위 태그가 포함됩니다. 'Tag' 필드는 'Type'이 'grandfathered' 또는 'redundant'인 레코드에 나타나며 [RFC3066]에 따라 등록된 태그를 포함합니다. 'Subtag' field-body는 2.1.1절에 설명된 대소문자 표기 관례를 따라야 합니다. 모든 하위 태그는 다음 두 가지 예외를 제외하고 field-body에서 소문자를 사용합니다. 'Type' 필드가 'script'인 하위 태그(즉, ISO 15924에서 정의한 하위 태그)는 첫 글자만 대문자로 표기해야 합니다. 'Type' 필드가 'region'인 하위 태그(즉, ISO 3166-1에서 정의한 숫자가 아닌 지역 하위 태그)는 모두 대문자로 표기해야 합니다. 'Tag' field-body는 2.1.1절에 설명된 규칙에 따라 형식을 지정해야 합니다. 3.1.5. Description 필드 'Description' 필드에는 레코드의 태그 또는 하위 태그에 대한 설명이 포함됩니다. 'Description' 필드는 한 레코드에서 두 번 이상 나타날 수 있습니다. 'Description' 필드에는 유니코드 문자의 전체 범위가 포함될 수 있습니다. 'Description' 필드 중 최소 하나는 라틴 문자로 작성되거나 전사되어야 하며, 추가 'Description' 필드는 어떠한 문자 체계나 언어로도 작성될 수 있습니다. 'Description' 필드는 식별 목적으로 사용됩니다. 설명에는 혼동될 수 있는 다른 하위 태그와 해당 하위 태그를 구별하는 데 필요한 정보만을 모두 포함하는 것이 좋습니다. 일반적인 배경 정보를 제공하거나 가능한 모든 대체 이름 또는 명칭을 제공하기 위한 것이 아닙니다. 'Description' 필드가 반드시 레코드 항목의 실제 고유 명칭을 나타내는 것은 아니며, 설명이 특정 언어(예: 영어 또는 프랑스어)로 되어 있다는 보장도 없습니다. Phillips & Davis 현재 최선의 관행 [26페이지]
RFC 5646 언어 태그 2009년 9월 레지스트리에서 ISO 639, ISO 15924, ISO 3166-1 또는 UN M.49 코드에 해당하는 설명은 해당 식별자가 레지스트리에 추가될 당시 원본 표준에서 정의된 의미 또는 안정성 규칙(3.4절)의 범위 안에서 이후 등록을 통해 변경된 의미를 나타내기 위한 것일 뿐입니다. 'Description'은 원본 표준 자체의 내용을 대체하지 않습니다. 'Description' 필드는 하위 태그에 대한 현지화된 영어 명칭이 되도록 의도된 것이 아닙니다. 언어 태그 및 하위 태그 설명의 현지화 또는 번역은 이 문서의 범위를 벗어납니다. 원본 표준(예: ISO 639 또는 ISO 15924)에서 가져온 하위 태그의 경우 레코드의 'Description' 필드도 처음에는 해당 원본 표준에서 가져옵니다. 원본 표준에 여러 설명이 있으면 각각 별도의 'Description' 필드로 나눕니다. 원본 표준의 설명은 삽입 전 또는 등록 절차를 통해 편집하거나 수정할 수 있으며, 추가적이거나 불필요한 설명은 생략하거나 제거할 수 있습니다. 각 'Description' 필드는 해당 필드가 나타나는 레코드 내에서 고유해야 하며, 동일한 설명의 형식상 변형은 해당 레코드에 나타나지 않는 것이 좋습니다. 예를 들어 ISO 639-1 코드 'fy'에는 해당 표준에서 "Western Frisian"과 "Frisian, Western"이라는 설명이 모두 있지만, 레지스트리에는 이러한 설명 중 하나만 나타납니다. 사용자가 어떤 하위 태그를 사용해야 하는지 혼동하지 않도록 특정 유형('language', 'extlang', 'script' 등)의 레코드에 할당되는 'Description' 필드는 다음 예외를 제외하고 해당 레코드 유형 안에서 고유해야 합니다. 특정 'Description' 필드가 특정 유형의 여러 레코드에 나타나는 경우, 그 레코드 중 최대 하나만 'Deprecated' 필드를 생략할 수 있습니다. 'Description'을 공유하는 모든 폐기된 레코드는 동일한 'Preferred-Value'를 가져야 하며, 폐기되지 않은 모든 레코드는 해당 'Preferred-Value'여야 합니다. 이는 동일한 유형의 두 레코드가 'Description'을 공유하면 의미상으로도 동등하며, 특정 'Description'의 의미에 대해 선호되는 레코드는 하나를 초과할 수 없음을 의미합니다. 예를 들어 'language' 하위 태그 'zza'(Zaza)와 'diq'(Dimli)를 생각해 보겠습니다. 'zza'는 'diq'를 포함하는 대언어이므로 ISO 639-3에서도 "Dimli"라는 설명을 갖습니다. 충돌을 방지하기 위해 'zza'의 레지스트리 레코드에서는 이 설명을 "Dimli (macrolanguage)"로 편집했습니다. 반면 하위 태그 'he'와 'iw'는 "Hebrew"라는 'Description' 값을 공유합니다. 이는 'iw'가 폐기되었고 그 'Preferred-Value'가 'he'이기 때문에 허용됩니다. Phillips & Davis 현재 최선의 관행 [27페이지]
RFC 5646 언어 태그 2009년 9월 'language' 유형의 필드에서는 레지스트리에 나타나는 첫 번째 'Description' 필드가 가능한 경우 ISO 639-3에서 할당한 Reference Name에 해당합니다. 이는 ISO 639와 레지스트리 간의 상호 참조를 용이하게 하는 데 도움이 됩니다. 원본 표준 중 하나의 조치로 인해 레코드를 생성하거나 업데이트할 때 언어 하위 태그 검토자는 제안된 레코드를 검토를 위해 ietf-languages@iana.org 목록에 제출하기 전에 형식의 불규칙성 (예: 철자 오류, 부적절한 아포스트로피나 기타 문장 부호, 과도하거나 누락된 공백)을 수정하도록 설명을 편집할 수 있습니다. 3.1.6. Deprecated 필드 'Deprecated' 필드에는 레코드가 폐기된 날짜가 포함되며 3.3절에 설명된 유지 관리 절차 또는 3.5절에 설명된 등록 절차를 통해 어떠한 레코드에도 추가, 변경 또는 제거될 수 있습니다. 일반적으로 'Deprecated' 필드의 추가는 ISO 3166과 같은 표준 기관이 코드를 철회한 결과입니다. 'Deprecated' 필드가 있는 하위 태그와 태그는 언어 태그에서 유효하지만 폐기된 것이며, 검증 처리기는 이러한 하위 태그를 생성하지 않는 것이 좋습니다. 'Deprecated' 필드를 포함하지만 대응하는 'Preferred-Value' 필드가 없는 레코드에는 대체 매핑이 없다는 점에 유의하십시오. 일부 역사적인 경우에는 원래의 폐기 날짜를 재구성하는 것이 불가능했을 수 있습니다. 이러한 경우 레지스트리에는 대략적인 날짜가 나타납니다. 일부 하위 태그와 일부 기존 또는 중복 태그는 레지스트리가 처음 생성되기 전에 폐기되었습니다. 이에 대한 정확한 규칙은 [RFC4645]의 2절에 나와 있습니다. 이러한 레코드에는 대응하는 'Added' 필드보다 더 이른 날짜의 'Deprecated' 필드가 있다는 점에 유의하십시오! 3.1.7. Preferred-Value 필드 'Preferred-Value' 필드에는 해당 필드가 나타나는 레코드와 다른 태그 또는 하위 태그(레코드의 'Type'에 따라 다름) 사이의 매핑이 포함됩니다. 이 필드의 값은 정규화에 사용됩니다(4.5절 참조). 하위 태그 또는 태그에 'Deprecated' 필드도 있는 경우, 언어 태그를 선택할 때 이 레코드의 값을 나타내기 위한 가장 좋은 선택으로 'Preferred-Value'를 사용하는 것이 권장됩니다. 'Preferred-Value'를 포함하는 레코드는 다음 네 그룹 중 하나에 속합니다. Phillips & Davis 현재 최선의 관행 [28페이지]
RFC 5646 언어 태그 2009년 9월 1. 나중에 다른 코드를 위해 철회된 ISO 639 언어 코드입니다. 이러한 값은 대부분 역사적인 참고 대상입니다. 위의 'he'/'iw' 쌍이 그 예입니다. 2. 새로운 코드를 위해 철회된 코드 또는 값에서 가져온 하위 태그 (language 또는 extlang 이외의 유형)입니다. 특히 이는 ISO 3166-1에서 가져온 지역 하위 태그에 적용됩니다. 국가가 때때로 새로운 지역 코드가 필요할 정도로 이름이나 행정 체계를 변경하기 때문입니다. 어떤 경우에는 국가가 이미 인코딩되어 있을 수 있는 이전 이름으로 되돌아가기도 합니다. 예를 들어 하위 태그 'ZR'(자이르)은 해당 국가의 이름이 변경되면서 하위 태그 'CD'(콩고 민주 공화국)로 대체되었습니다. 3. 나타내는 값이 나중에 인코딩되어 더 이상 사용되지 않게 된 태그 또는 하위 태그입니다. 예를 들어 많은 기존 또는 중복 태그가 나중에 ISO 639에 의해 인코딩되었으며 이 그룹에 속합니다. 예를 들어 "i-klingon"은 하위 태그 'tlh'가 추가되었을 때 폐기되었습니다. "i-klingon"의 레코드에는 'tlh'라는 'Preferred-Value'가 있습니다. 4. 확장 언어 하위 태그에는 항상 동일한 기본 언어 하위 태그로의 매핑이 있습니다. 예를 들어 확장 언어 하위 태그 'yue'(광둥어)는 태그 "zh-yue"를 구성하는 데 사용할 수 있습니다. 이 하위 태그에는 기본 언어 하위 태그 'yue'로의 'Preferred-Value' 매핑이 있으므로 "zh-yue-Hant-HK"와 같은 태그는 "yue-Hant-HK"로 정규화할 수 있습니다. 'Preferred- Value' 필드를 포함하는 'extlang' 유형 이외의 레코드에는 'Deprecated' 필드도 있어야 합니다. 이 필드는 선호 값으로 인해 태그 또는 하위 태그가 폐기된 날짜를 포함합니다. 'extlang' 유형의 레코드에서는 'Preferred-Value' 필드가 대응하는 'Deprecated' 필드 없이 나타납니다. 구현은 이러한 선호 값 매핑을 무시할 수 있지만, 매핑을 무시한다면 일관되게 무시하는 것이 좋습니다. 또한 'Preferred-Value'를 매핑된 항목과 동등하게 취급하는 것이 좋습니다. 예를 들어 태그 "zh-yue-Hant-HK"와 "yue-Hant-HK"는 의미상 동등하며 동일한 태그인 것처럼 취급하는 것이 적절합니다. 때로는 폐기된 코드가 특정 상황에서 선호됩니다. 예를 들어 Java 프로그래밍 언어에서는 "iw"와 "he"를 모두 사용할 수 있지만, "he"는 입력 시 "iw"로 변환되므로 Java에서는 "iw"가 정규 형식입니다. Phillips & Davis 현재 최선의 관행 [29페이지]
RFC 5646 언어 태그 2009년 9월 'region' 유형 레코드의 'Preferred-Value' 매핑은 때때로 원래 값과 정확히 동일한 의미를 나타내지 않습니다. 국가 코드가 변경되는 데에는 여러 이유가 있으며, 이러한 변경이 언어 태그 구성에 미치는 영향은 해당 변경의 성격에 따라 달라집니다. 예를 들어 지역 하위 태그 'YD'(남예멘)는 두 국가가 1990년에 통일되면서 하위 태그 'YE'(예멘)를 위해 폐기되었습니다. 'Preferred-Value'는 3.3절의 규칙에 따라 레코드에 추가, 변경 또는 제거될 수 있습니다. 레코드에서 'Preferred-Value' 필드를 추가, 수정 또는 제거했다고 해서 영향을 받는 하위 태그를 사용하는 콘텐츠에 태그를 다시 지정해야 한다는 의미는 아닙니다. "grandfathered" 및 "redundant" 유형 레코드의 'Preferred-Value' 필드는 각각 해당 레코드의 값 대신 사용하는 것이 매우 강하게 권장되는 "확장 언어 범위" [RFC4647]를 포함합니다. 많은 경우 이러한 매핑은 [RFC4646]이 채택되기 전 기간에 태그를 폐기하는 과정에서 생성되었습니다. 예를 들어 태그 "no-nyn"은 ISO 639-1에서 정의한 언어 코드 'nn'을 위해 폐기되었습니다. "extlang" 유형 하위 태그 레코드의 'Preferred-Value' 필드도 "확장 언어 범위"를 포함합니다. 이를 통해 하위 태그를 하나의 기본 언어 하위 태그 또는 새로운 language-extlang 시퀀스를 위해 폐기할 수 있습니다. 일반적으로 하위 태그의 'Preferred-Value' 필드를 추가, 제거 또는 변경하는 것은 원본 표준 중 하나의 변경 사항을 반영하기 위해 이루어집니다. 예를 들어 ISO 3166-1 지역 코드가 다른 코드를 위해 폐기되면 'Preferred-Value' 필드가 추가되는 것이 좋습니다. 하나의 하위 태그에 대한 변경은 다른 하위 태그에도 영향을 줄 수 있습니다. 레지스트리 변경을 제안할 때 언어 하위 태그 검토자는 이러한 영향을 확인하기 위해 레지스트리를 검토하고 3.5절의 절차를 사용하여 필요한 변경 사항을 제안해야 합니다. 다만 누구나 이러한 변경을 요청할 수 있습니다. 예를 들면 다음과 같습니다. 하위 태그 'XX'의 'Preferred-Value'가 'YY'라고 가정합니다. 나중에 'YY'가 변경되어 'Preferred-Value'가 'ZZ'가 되면, 'XX'의 'Preferred-Value' 역시 'ZZ'로 변경되어야 합니다. 등록된 언어 하위 태그 'dialect'가 아직 ISO 639의 어느 부분에도 없는 언어를 나타낸다고 가정합니다. 이후 ISO 639에 대응하는 언어 코드가 추가되면 'dialect'에 'Preferred-Value'가 추가되는 것이 좋습니다. Phillips & Davis 현재 최선의 관행 [30페이지]
RFC 5646 언어 태그 2009년 9월 3.1.8. Prefix 필드 'Prefix' 필드에는 다른 하위 태그와 함께 사용할 수도 있는 이 레코드의 하위 태그에 가능한 접두사 중 하나로 권장되는 유효한 언어 태그가 포함됩니다. 즉, 하나 이상의 'Prefix'를 가진 확장 언어 또는 변형 하위 태그를 언어 태그에 포함할 때 결과 태그는 "Extended Filtering" 알고리즘([RFC4647] 참조)을 사용하여 하위 태그의 'Prefix' 필드 중 최소 하나와 일치하는 것이 좋으며, 해당 'Prefix'에 있는 각 하위 태그는 하위 태그 자체보다 앞에 나타나는 것이 좋습니다. 'Prefix' 필드는 'extlang' 유형의 레코드에 정확히 한 번 나타나야 합니다. 'Prefix' 필드는 'variant' 유형의 레코드에는 여러 번 나타날 수 있으며, 전혀 나타나지 않을 수도 있습니다. 'variant' 레코드에 이미 하나 이상의 'Prefix' 필드가 있는 경우 등록 절차를 통해 이 유형의 필드를 추가할 수 있습니다. 각 'Prefix' 필드는 이 하위 태그와 함께 의미 있는 태그를 구성하는 특정 하위 태그 시퀀스를 나타냅니다. 예를 들어 확장 언어 하위 태그 'cmn'(관화)은 그 접두사 'zh'(중국어)와 함께 사용할 때만 의미가 있습니다. 마찬가지로 'rozaj'(슬로베니아어의 방언인 Resian)는 접두사 'sl'(슬로베니아어)과 함께 사용할 때 적절하지만, "is-1994"와 같은 태그는 적절하지 않습니다(아마 의미도 없을 것입니다). 'rozaj'의 'Prefix'는 "sl"이지만 이 둘 사이에 다른 하위 태그가 나타날 수 있습니다. 예를 들어 태그 "sl- IT-rozaj"(슬로베니아어, 이탈리아, Resian)는 'Prefix' "sl"과 일치합니다. 'Prefix'는 변형 하위 태그를 함께 사용할 때 의미가 있는 경우 (그렇지 않으면 동일한 'Prefix'를 공유하는 많은 변형은 상호 배타적임)와 변형의 상대적 순서가 어떻게 되어야 하는지도 나타냅니다. 예를 들어 변형 '1994'(표준화된 Resian 철자법)는 레지스트리에 여러 'Prefix' 필드("sl-rozaj", "sl-rozaj-biske", "sl-rozaj-njiva", "sl-rozaj-osojs", "sl-rozaj- solba")를 가집니다. 이는 '1994'를 이 다섯 개의 Resian 변형 하위 태그('rozaj', 'biske', 'njiva', 'osojs', 'solba') 각각과 함께 사용하는 것이 적절하다는 것뿐 아니라 태그에서 이러한 변형 뒤에 나타나는 것이 좋다는 것도 의미합니다. 따라서 언어 태그는 "sl-1994- rozaj-biske" 또는 "sl-rozaj-1994-biske"가 아니라 "sl-rozaj-biske-1994" 형식을 취하는 것이 적절합니다. 레코드에 'Prefix' 필드가 없으면 나중에 해당 레코드에 'Prefix' 필드를 추가해서는 안 됩니다. 그렇지 않은 경우 권장되는 언어 태그의 범위를 엄격하게 넓히는 한 'Prefix' 필드 집합에 대한 변경(추가, 삭제 또는 수정)을 등록할 수 있습니다. 예를 들어 값이 "be- Latn"(벨라루스어, 라틴 문자)인 'Prefix'는 값 "be"(벨라루스어)로 대체할 수 있지만 값 "ru-Latn"(러시아어, 라틴 문자) 또는 Phillips & Davis 현재 최선의 관행 [31페이지]
RFC 5646 언어 태그 2009년 9월 값 "be-Latn-BY"(벨라루스어, 라틴 문자, 벨라루스)로는 대체할 수 없습니다. 후자의 값들은 제안되는 태그의 범위를 변경하거나 좁히기 때문입니다. 'Prefix' 필드의 field-body는 특정 레코드에 이미 등록된 어떠한 'Prefix'와도 충돌해서는 안 됩니다. 이러한 충돌은 두 하위 태그가 각각 다른 하위 태그를 포함하는 'Prefix'를 갖는 경우처럼 해당 접두사를 포함하는 유효한 태그를 구성할 수 없을 때 발생합니다. 예를 들어 하위 태그 'avariant'의 접두사가 "es-bvariant"라고 가정합니다. 그러면 하위 태그 'bvariant'에는 접두사 'avariant'를 할당할 수 없습니다. 그렇게 하면 "es-avariant-bvariant-avariant" 형식의 태그가 필요하지만 이는 유효하지 않기 때문입니다. 3.1.9. Suppress-Script 필드 'Suppress-Script' 필드에는 문자 체계 하위 태그(그 레코드는 레지스트리에 나타남)가 포함됩니다. 'Suppress-Script' 필드는 'Type' field-body가 'language' 또는 'extlang'인 레코드에만 나타나야 합니다. 이 필드는 한 레코드에 두 번 이상 나타나서는 안 됩니다. 이 필드는 해당 언어의 문서 중 압도적 다수를 작성하는 데 사용되는 문자 체계를 나타냅니다. 따라서 이러한 문자 체계의 하위 태그는 언어 태그에 구별되는 정보를 추가하지 않으므로 해당 언어로 된 대부분의 문서에는 사용하지 않는 것이 좋습니다. 이 필드가 나타내는 문자 체계 하위 태그를 생략하면 이 문서의 규칙에 따라 생성된 언어 태그와 RFC 3066에 기반한 언어 태그 및 태그 처리기 또는 소비자 사이의 호환성을 높이는 데 도움이 됩니다. 예를 들어 거의 모든 아이슬란드어 문서는 라틴 문자로 작성되므로 태그 "is-Latn"에서 하위 태그 'Latn'은 중복됩니다. 많은 언어 하위 태그 레코드에는 'Suppress-Script' 필드가 없습니다. 'Suppress-Script'가 없다는 것은 해당 언어가 일반적으로 둘 이상의 문자 체계로 작성되거나 일반적으로 문자로 작성되지 않는다는 의미일 수 있습니다. 또한 레코드를 만들 당시 충분한 정보를 사용할 수 없었기 때문에 향후 등록 후보로 남아 있다는 의미일 수도 있습니다. 3.1.10. Macrolanguage 필드 'Macrolanguage' 필드에는 기본 언어 하위 태그(그 레코드는 레지스트리에 나타남)가 포함됩니다. 이 필드는 ISO 639-3의 할당에 따라 이 하위 태그의 언어를 포괄하는 언어를 나타냅니다. ISO 639-3은 레지스트리의 일부 언어를 "대언어"로 표시합니다. ISO 639-3은 "macrolanguage"라는 용어를 "서로 밀접하게 관련된 Phillips & Davis 현재 최선의 관행 [32페이지]
RFC 5646 언어 태그 2009년 9월 언어 변종의 집합으로서 [...] 서로 구별되는 개별 언어로 간주될 수 있지만, 특정 사용 상황에서는 모두에 대해 하나의 언어 정체성이 필요한 것"을 의미한다고 정의합니다. 이는 ISO 639-2에서 개별 언어로 등록된 코드 중 ISO 639-3에서는 둘 이상의 언어에 해당하는 것으로 밝혀진 코드에 대응합니다. 대언어 안에 포함되는 언어를 "포괄된 언어"라고 합니다. 각 포괄된 언어의 레코드는 레지스트리에 'Macrolanguage' 필드를 포함하지만, 대언어 자체에는 특별한 표시가 없습니다. 일부 포괄된 언어에는 ISO 639-1 또는 ISO 639-2 코드가 있다는 점에 유의하십시오. 'Macrolanguage' 필드는 'language' 또는 'extlang' 유형의 레코드에만 나타날 수 있습니다. ISO 639-3에서 할당한 값만 포함 대상으로 고려됩니다. ISO 639-3에서 새로운 값을 정의하거나 기존 값을 철회할 때마다 일반적인 등록 절차를 통해 'Macrolanguage' 필드를 추가하거나 제거할 수 있습니다. 대언어 정보는 정보 제공용이며, ISO 639-3이 값을 변경하면 제거하거나 변경할 수 있습니다. 이 필드의 사용과 대언어 및 포괄된 언어 하위 태그 사이에서 선택하는 방법에 관한 자세한 내용은 4.1.1절을 참조하십시오. 예를 들어 언어 하위 태그 'nb'(노르웨이어 보크몰)와 'nn' (노르웨이어 뉘노르스크)은 각각 값이 'no'(노르웨이어)인 'Macrolanguage' 필드를 가집니다. 자세한 내용은 4.1절을 참조하십시오. 3.1.11. Scope 필드 'Scope' 필드에는 ISO 639에서 파생된 기본 또는 확장 언어 하위 태그에 관한 분류 정보가 포함됩니다. 대부분의 언어에는 'individual' 범위가 있으며, 이는 해당 언어가 대언어, 집합, 특수 코드 또는 사적 사용이 아님을 의미합니다. 즉, 일반적으로 '하나의 언어'라고 생각하는 것입니다. 'Scope' 필드가 없는 모든 기본 또는 확장 언어 하위 태그는 개별 언어입니다. 'Scope' 정보는 ISO 639에서 코드 할당의 목적 또는 "범위"를 나타내므로 언어 태그를 선택할 때 도움이 될 수 있습니다. 사용 가능한 값은 다음과 같습니다. o 'macrolanguage' - ISO 639-3에서 정의한 대언어를 나타냅니다 (3.1.10절 참조). 대언어는 때때로 하나의 언어로 간주되는 서로 밀접하게 관련된 언어의 집합입니다. o 'collection' - 일반적으로 역사적, 지리적 또는 언어학적 연관성으로 관련된 언어 집합을 나타내는 하위 태그입니다. 대언어와 달리 Phillips & Davis 현재 최선의 관행 [33페이지]
RFC 5646 언어 태그 2009년 9월 집합은 서로 느슨하게 관련된 언어를 포함할 수 있으며 집합을 그 안에 속한 언어와 서로 바꾸어 사용할 수 없습니다. o 'special' - 특수 언어 코드를 나타냅니다. 이는 구체적인 언어와 특별히 연관되지 않은 언어적 속성을 식별하는 데 사용되는 하위 태그입니다. 여기에는 언어가 결정되지 않은 경우 또는 비언어적 콘텐츠를 위한 코드가 포함됩니다. o 'private-use' - 기반 표준에서 사적 사용을 위해 예약된 코드를 나타냅니다. 이 범위를 가진 하위 태그는 ISO 639 또는 등록된 할당이 존재하지 않는 기본 언어를 나타내는 데 사용할 수 있습니다. 'Scope' 필드는 'language' 또는 'extlang' 유형의 레코드에 나타날 수 있습니다. 확장 언어 하위 태그의 접두사 중 다수는 'macrolanguage'라는 'Scope'를 가질 것이며(일부는 그렇지 않음), 'macrolanguage'라는 'Scope'를 가진 많은 언어에는 관련 확장 언어 하위 태그가 있다는 점에 유의하십시오. 'Scope' 필드는 변경 사항이 ISO 639가 할당의 분류에 적용한 변경을 반영하는 경우 등록 절차를 통해 추가, 수정 또는 제거할 수 있습니다. 이러한 변경은 드물 것으로 예상됩니다. 예를 들어 기본 언어 하위 태그 'zh'(중국어)의 'Scope'는 'macrolanguage'이고, 그 안에 포함된 언어 'nan'(민난어)의 'Scope'는 'individual'입니다. 특수 값 'und'(미결정)의 'Scope'는 'special'입니다. ISO 639-5 집합 'gem'(게르만어족)의 'Scope'는 'collection'입니다. 3.1.12. Comments 필드 'Comments' 필드에는 레코드에 관한 추가 정보가 포함되며 한 레코드에 두 번 이상 나타날 수 있습니다. field-body에는 유니코드 문자의 전체 범위가 포함될 수 있으며 특정 문자 체계로 제한되지 않습니다. 이 필드는 등록 절차를 통해 삽입하거나 변경할 수 있으며 안정성은 보장되지 않습니다. 이 필드의 내용은 정보를 등록해야 한다는 필요성, 요청의 적절성, 합리적인 실제 크기 제한을 제외하면 제한되지 않습니다. 'Comments' 필드의 주된 이유는 하위 태그 식별, 즉 사용을 돕기 위해 혼동될 수 있는 다른 하위 태그와 해당 하위 태그를 구별하는 것입니다. 하위 태그의 사용, 역사 또는 일반적인 배경에 관한 많은 양의 정보는 권장되지 않습니다. 이러한 정보는 일반적으로 레지스트리보다 등록 요청에 포함되는 것이 적절하기 때문입니다. Phillips & Davis 현재 최선의 관행 [34페이지]
RFC 5646 언어 태그 2009년 9월 3.2. 언어 하위 태그 검토자 언어 하위 태그 검토자는 ietf-languages@iana.org 메일링 리스트를 관리하고 등록 요청에 응답하며 3.3절에 설명된 기타 레지스트리 유지 관리 업무를 수행합니다. 언어 하위 태그 검토자만 IANA에 언어 하위 태그 레지스트리의 레코드를 변경, 업데이트 또는 추가하도록 요청할 수 있습니다. 언어 하위 태그 검토자는 필요에 따라 목록 관리 및 기타 사무 업무를 위임할 수 있습니다. 언어 하위 태그 검토자는 IESG가 임기 제한 없이 임명하며, IESG의 재량에 따라 해임되거나 교체될 수 있습니다. IESG는 (이 문서가 채택되거나 공석이 발생하면) 해당 직책의 후보자를 모집한 뒤 후보자의 자격에 관한 의견을 수렴합니다. 자격 있는 후보자는 BCP 47 및 그 요구 사항에 익숙하고, 등록 절차를 공정하고 신속하며 신중하게 관리할 의향이 있어야 하며, 검토자가 주장 내용을 평가하고 언어 전문가와 하위 태그 요청자의 기여를 활용할 수 있도록 언어 식별 문제에 관해 충분한 지식을 갖추는 것이 좋습니다. 언어 하위 태그 검토자의 이후 업무 수행 또는 결정은 다른 IETF 결정과 동일한 규칙에 따라 IESG에 이의를 제기할 수 있습니다 ([RFC2026] 참조). IESG는 언어 하위 태그 검토자의 결정을 뒤집거나 무효화하고, 지침을 제공하거나 기타 적절한 조치를 취할 수 있습니다. 3.3. 레지스트리 유지 관리 레지스트리 유지 관리에서는 ISO 639, ISO 15924, ISO 3166 및 UN M.49에서 코드가 할당되거나 철회될 때 언어 하위 태그 검토자가 각 변경 사항을 평가하고 이 문서의 규칙에 따라 적절한 조치를 결정해야 합니다. 이러한 업데이트는 3.5절에 설명된 등록 절차를 따릅니다. 일반적으로 언어 하위 태그 검토자가 등록 양식을 작성하여 제출함으로써 새 레코드 또는 업데이트된 레코드에 대한 절차를 시작합니다. 이러한 표준 중 하나에 변경 사항이 발생했는데 언어 하위 태그 검토자가 적시에 이를 수행하지 않는 경우 이해관계가 있는 누구나 양식을 제출할 수 있습니다. 이후 등록 절차는 정상적으로 계속됩니다. 일부 등록은 지역 하위 태그가 새로운 값을 위해 폐기되는 경우처럼 다른 하위 태그, 경우에 따라 둘 이상의 하위 태그에 영향을 미친다는 점에 유의하십시오. 언어 하위 태그 검토자는 이러한 모든 변경이 적절하게 등록되도록 할 책임이 있으며, 각 변경에는 자체 등록 양식이 필요합니다. Phillips & Davis 현재 최선의 관행 [35페이지]
RFC 5646 언어 태그 2009년 9월 언어 하위 태그 검토자는 새로운 하위 태그가 이 문서의 다른 곳 (특히 3.4절)에 있는 요구 사항을 충족하는지 확인하거나 해당 절에 설명된 대체 하위 태그에 대한 적절한 등록 양식을 제출해야 합니다. 변경의 영향을 받는 각 개별 하위 태그는 자체 등록 양식과 별도의 메시지로 ietf-languages@iana.org 목록에 보내야 합니다. 3.4. IANA 레지스트리 항목의 안정성 레지스트리 항목과 그 의미의 안정성은 언어 태그의 장기적인 안정성에 매우 중요합니다. 이 절의 규칙은 특정 언어 태그의 의미가 시간이 지나도 안정적으로 유지되며 변경되지 않도록 보장합니다. 이 규칙은 특히 ISO 639, ISO 15924, ISO 3166 및 UN M.49에서 유지 관리하는 코드의 변경(코드의 철회 및 폐기 포함)이 IANA 언어 하위 태그 레지스트리에 반영되는 방식을 다룹니다. IANA 언어 하위 태그 레지스트리에 대한 할당은 다음 안정성 규칙을 따라야 합니다. 1. 'Type', 'Subtag', 'Tag', 'Added' 필드의 값은 변경해서는 안 되며 시간이 지나도 안정적으로 유지됨이 보장됩니다. 2. 'Preferred-Value' 및 'Deprecated' 필드의 값은 등록 절차를 통해 추가, 변경 또는 제거할 수 있습니다. 이러한 변경은 기반 표준(ISO 639, ISO 15924, ISO 3166-1 또는 UN M.49) 중 하나의 변경을 반영하는 데 필요한 변경으로 제한하는 것이 좋으며, 일반적으로 'Preferred-Value'의 변경 또는 제거는 특히 지역 코드로 제한됩니다. 3. 'Description' 필드의 값은 기존 태그를 무효화하는 방식으로 변경해서는 안 됩니다. 설명은 범위를 어느 정도 넓히거나, 정보를 추가하도록 변경하거나, 가장 일반적인 현대적 용법에 맞게 조정할 수 있습니다. 예를 들어 국가는 때때로 이름을 변경합니다. 역사적인 예로 "Upper Volta"가 "Burkina Faso"로 변경된 경우가 있습니다. 4. 'variant' 유형의 기존 레코드에 있는 'Prefix' 필드의 값은 해당 'variant'에 이미 하나 이상의 'Prefix'가 있는 경우 등록 절차를 통해 추가할 수 있습니다. 기존 'Prefix' 필드가 없는 어떠한 'variant'에도 'Prefix' 필드를 등록해서는 안 됩니다. 변형 레코드에 접두사가 추가되는 경우 'Comment' 필드를 사용하여 여러 접두사의 서로 다른 용법을 설명할 수 있습니다. Phillips & Davis 현재 최선의 관행 [36페이지]
RFC 5646 언어 태그 2009년 9월 5. 'variant' 유형 레코드의 'Prefix' 필드 값은 접두사 집합을 넓히는 한 수정할 수도 있습니다. 즉, 하나의 접두사를 그 자체의 접두사 중 하나로 대체할 수 있습니다. 예를 들어 접두사 "en-US"는 "en"으로 대체할 수 있지만, "en-Latn", "fr" 또는 "en-US- boont" 접두사로는 대체할 수 없습니다. 이러한 접두사 값 중 하나가 필요하다면 별도로 등록해야 합니다. 6. 'extlang' 유형 레코드의 'Prefix' 필드 값은 추가, 수정 또는 제거해서는 안 됩니다. 7. 'Prefix' 필드는 해당 필드가 나타나는 어떠한 레코드에서도 제거해서는 안 됩니다. 이 필드는 'variant' 유형 레코드의 최초 등록에 포함하는 것이 좋으며 'extlang' 유형의 모든 레코드에는 반드시 포함해야 합니다. 8. 'Comments' 필드는 등록 절차 또는 이 절에 설명된 절차나 고려 사항을 통해 추가, 변경, 수정 또는 제거할 수 있습니다. 9. 'Suppress-Script' 필드는 등록 절차를 통해 추가하거나 제거할 수 있습니다. 10. 'Macrolanguage' 필드는 등록 절차를 통해 추가하거나 제거할 수 있지만 ISO 639가 변경한 사항에 대응하는 경우에만 가능합니다. 'Macrolanguage' 필드는 언어에 ISO 639의 대응하는 대언어가 있을 때마다 나타납니다. 즉, 레지스트리의 'Macrolanguage' 필드는 ISO 639의 해당 항목과 정확히 일치합니다. 그 밖의 대언어 매핑은 등록 대상으로 고려되지 않습니다. 11. 'Scope' 필드는 최초 등록 이후 기본 또는 확장 언어 하위 태그에 추가하거나 제거할 수 있으며 ISO 639가 적용한 변경과 일치하도록 수정할 수도 있습니다. 'Scope' 필드의 변경은 ISO 639의 변경을 반영해야 합니다. 레코드에 'Scope' 필드가 없는 기본 또는 확장 언어 하위 태그(즉, 대부분의 하위 태그)는 3.1.11절에 설명된 개별 언어라는 점에 유의하십시오. 12. 기본 및 확장 언어 하위 태그(등록 절차를 사용하여 생성된 독립적으로 등록된 값 제외)는 ISO 639의 여러 부분에서 이루어진 할당에 따라 다음과 같이 생성됩니다. A. 기존 두 글자 기본 언어 하위 태그와 충돌하지 않고 레지스트리에 정의된 대응하는 세 글자 기본 언어가 없는 ISO 639-1에서 할당한 코드는 새 레코드로 IANA 레지스트리에 Phillips & Davis 현재 최선의 관행 [37페이지]
RFC 5646 언어 태그 2009년 9월 'language' 유형으로 입력됩니다. ISO 639-1 코드가 부여된 언어에는 대언어에 포함되더라도 확장 언어 하위 태그를 부여할 수 없다는 점에 유의하십시오. B. 기존 세 글자 기본 언어 하위 태그와 충돌하지 않으며 ISO 639-1 코드가 할당되지 않았거나(또는 할당될 것으로 예상되지 않는) ISO 639-3 또는 ISO 639-5에서 할당한 코드는 'language' 유형의 새 레코드로 IANA 레지스트리에 입력됩니다. 이 두 표준은 현재 ISO 639-2 코드의 상위 집합을 구성한다는 점에 유의하십시오. 등록 시점에 정의된 'macrolanguage' 매핑이 있는 코드는 반드시 'Macrolanguage' 필드를 포함해야 합니다. C. ISO 639-3에서 할당한 코드는 확장 언어 하위 태그 등록 대상으로 고려할 수도 있습니다. 'extlang' 레코드가 제안되는 경우에도 반드시 'language' 유형의 기본 언어 하위 태그 레코드를 할당해야 한다는 점에 유의하십시오. 확장 언어 하위 태그 할당을 고려할 때는 다음 기준이 적용됩니다. 1. 언어에 대언어 매핑이 있고 해당 대언어에 확장 언어 하위 태그가 할당된 다른 포괄 언어가 있다면, 새 언어에도 'extlang' 레코드를 할당하는 것이 좋습니다. 예를 들어 대언어가 'zh' 또는 'ar'인 모든 언어에는 'extlang' 레코드가 할당됩니다. 2. 대언어에 포함된 다른 언어에도 'extlang' 레코드가 없는 경우 해당 언어에 'Extlang' 레코드를 생성하지 않는 것이 좋습니다. 예를 들어 새로운 세르보크로아트어 ('sh') 언어가 등록되더라도 세르비아어('sr')와 같은 다른 포괄 언어에 레지스트리의 extlang 레코드가 없으므로 extlang 레코드를 갖지 않습니다. 3. 수어에는 'sgn'이라는 'Prefix'를 가진 'extlang' 레코드를 두는 것이 좋습니다. 4. 이미 레지스트리에 있는 항목에 대해서는 'Extlang' 레코드를 생성해서는 안 됩니다. 확장 언어 하위 태그는 최초 등록 시에만 고려됩니다. 5. 확장 언어 하위 태그 레코드는 2.2.2절에 설명된 대로 할당된 필드 값을 가진 'Prefix' 및 'Preferred-Value' 필드를 포함해야 합니다. D. 기존 세 글자 기본 또는 확장 언어 하위 태그와 충돌하지 Phillips & Davis 현재 최선의 관행 [38페이지]
RFC 5646 언어 태그 2009년 9월 않고 ISO 639-1 두 글자 코드가 할당되지 않은 ISO 639-2의 다른 모든 코드는 'language' 유형의 새 레코드로 IANA 레지스트리에 입력됩니다. 이러한 유형의 등록은 앞으로 발생하지 않을 것으로 예상됩니다. 13. 관련 유형의 기존 하위 태그와 충돌하지 않고 그 의미가 동일한 유형의 기존 하위 태그와 같지 않은 ISO 15924 및 ISO 3166-1 할당 코드는 새 레코드로 IANA 레지스트리에 입력됩니다. 14. ISO 639, ISO 15924 또는 ISO 3166-1에서 할당한 코드가 각각의 유지 관리 기관 또는 등록 기관에 의해 철회되더라도 언어 태그에서는 계속 유효합니다. 철회 날짜가 포함된 'Deprecated' 필드를 레코드에 추가해야 합니다. 동일한 유형에서 대체 값을 나타내는 새 레코드가 추가되는 경우 'Preferred-Value' 필드도 추가할 수 있습니다. 등록 절차를 사용하여 해당 표준에서 코드를 철회한 것에 관한 설명을 추가할 수도 있습니다. 예: 지역 코드 'TL'은 'Timor-Leste' 국가에 할당되어, 포르투갈의 통치하에 있을 당시 'East Timor'에 할당되었던 코드 'TP'를 대체했습니다. 하위 태그 'TP'는 언어 태그에서 계속 유효하지만, 그 레코드에는 'TL'이라는 'Preferred-Value'가 있으며 'Deprecated' 필드에는 새 코드가 할당된 날짜('2004-07-06')가 포함됩니다. 15. ISO 639, ISO 15924 또는 ISO 3166-1에서 할당한 코드가 폐기된 하위 태그를 포함하여 관련 유형의 기존 하위 태그와 충돌하는 경우 레지스트리에 입력해서는 안 됩니다. 재할당되는 하위 태그 값에는 다음과 같은 추가 고려 사항이 적용됩니다. A. ISO 639 코드의 경우 새로 할당된 코드의 의미가 IANA 레지스트리의 하위 태그로 나타나 있지 않다면, 3.5절에 설명된 언어 하위 태그 검토자는 가능한 한 신속하게 새 코드의 대체 값으로 등록된 언어 하위 태그를 IANA 레지스트리에 입력하기 위한 제안을 준비해야 합니다. 등록되는 언어 하위 태그의 형식은 언어 하위 태그 검토자의 재량에 따르며 이 문서의 언어 하위 태그에 대한 다른 제한을 준수해야 합니다. B. 외부 표준(즉, ISO 639, ISO 15924, ISO 3166-1 또는 UN M.49)에서 의미가 파생된 모든 하위 태그의 경우, 기존 코드에 새로운 의미가 할당되고 그 새로운 의미가 해당 코드의 의미를 넓힌다면 관련 하위 태그의 의미를 이에 맞게 변경할 수 있습니다. Phillips & Davis 현재 최선의 관행 [39페이지]
RFC 5646 언어 태그 2009년 9월 그러나 하위 태그의 의미를 좁혀서는 안 됩니다. 그렇게 하면 기존 하위 태그 사용 중 알 수 없는 비율이 유효하지 않게 될 수 있기 때문입니다. 참고: ISO 639 등록 기관(RA)도 유사한 안정성 정책을 채택했습니다. C. ISO 15924 코드의 경우 새로 할당된 코드의 의미가 IANA 레지스트리의 하위 태그로 나타나 있지 않다면, 3.5절에 설명된 언어 하위 태그 검토자는 가능한 한 신속하게 새 코드의 대체 값으로 등록된 변형 하위 태그를 IANA 레지스트리에 입력하기 위한 제안을 준비해야 합니다. 등록되는 변형 하위 태그의 형식은 언어 하위 태그 검토자의 재량에 따르며 이 문서의 변형 하위 태그에 대한 다른 제한을 준수해야 합니다. D. ISO 3166-1 코드의 경우 새로 할당된 코드의 의미가 다른 'region' 하위 태그와 동일한 UN M.49 코드와 연결된다면, 기존 지역 하위 태그가 해당 지역의 선호 값으로 유지되며 새 항목은 생성되지 않습니다. 새 ISO 3166-1 코드와의 관계를 나타내는 설명을 기존 지역 하위 태그에 추가할 수 있습니다. E. ISO 3166-1 코드의 경우 새로 할당된 코드의 의미가 기존 지역 하위 태그로 나타나 있지 않은 UN M.49 코드와 연결된다면, 3.5절에 설명된 언어 하위 태그 검토자는 적절한 UN M.49 국가 코드를 IANA 레지스트리의 항목으로 입력하기 위한 제안을 준비해야 합니다. F. ISO 3166-1 코드에 관련 UN 숫자 코드가 없는 경우 언어 하위 태그 검토자는 UN에 해당 코드를 생성해 달라고 요청해야 합니다. 요청을 보낸 뒤 90일 이내에 UN의 응답이 없다면, 언어 하위 태그 검토자는 가능한 한 신속하게 새 코드의 대체 값으로 등록된 변형 하위 태그를 IANA 레지스트리에 입력하기 위한 제안을 준비해야 합니다. 등록되는 변형 하위 태그의 형식은 언어 하위 태그 검토자의 재량에 따르며 이 문서의 변형 하위 태그에 대한 다른 제한을 준수해야 합니다. 이러한 상황은 실제로 발생할 가능성이 매우 낮습니다. 16. UN M.49에는 "국가 및 지역"(예: 독일의 '276')과 "지리적 지역 및 하위 지역"(예: 유럽의 '150') 모두에 대한 코드가 있습니다. 대응하는 ISO 3166-1 코드가 없는 UN M.49 국가 또는 지역 코드는 기존 하위 태그 때문에 등록이 차단된 ISO 3166-1 코드의 대체 값으로 사용하는 경우를 제외하고 등록해서는 안 됩니다. Phillips & Davis 현재 최선의 관행 [40페이지]
RFC 5646 언어 태그 2009년 9월 이러한 코드가 필요하게 되면 먼저 ISO 3166-1 유지 관리 기관에 해당 지역에 코드를 할당해 달라고 요청해야 합니다. ISO 3166-1의 코드 할당 요청이 거부되거나 적시에 처리되지 않으면 3.5절에 설명된 등록 절차를 사용하여 대응하는 UN M.49 코드를 등록할 수 있습니다. 이렇게 하면 ISO 3166-1이 레지스트리에서 폐기된 값을 재할당하는 경우 UN M.49 코드를 최후의 수단으로 사용할 수 있습니다. 17. 중복 및 기존 항목을 합하면 [RFC3066]에 따라 등록된 태그의 전체 목록을 구성합니다. 중복 태그는 이전에 등록된 태그 중 이제 레지스트리에 정의된 하위 태그를 사용하여 구성할 수 있는 태그입니다. 기존 항목에는 'irregular'하기 때문에 절대로 적법할 수 없는 항목(즉, 그림 1의 'langtag' 생성 규칙과 일치하지 않음), 규칙에 의해 제한되는 항목('nyn' 및 'min'과 같은 하위 태그는 extlang 생성 규칙처럼 보이지만 확장 언어 하위 태그로 등록할 수 없음), 또는 그 하위 태그가 등록에 적합하지 않은 항목이 포함됩니다. 모든 기존 태그는 ABNF의 'regular' 또는 'irregular' 생성 규칙 중 하나에 나열되어 있습니다. [RFC4646]에서는 기존 태그가 중복 태그가 될 수 있었습니다. 그러나 그렇게 될 수 있었던 모든 태그는 이 문서가 작성되기 전에 이미 중복 태그가 되었습니다. 따라서 중복 및 기존 태그 집합은 이제 영구적이며 변경할 수 없습니다. 어느 유형에도 새 항목을 추가해서는 안 되며 기존 항목을 제거해서도 안 됩니다. 처음에 어떤 태그를 기존 태그로 지정하고 어떤 태그를 중복 태그로 만들었는지에 관한 결정 절차는 [RFC4645]에 설명되어 있습니다. 많은 기존 태그는 폐기되었습니다. 실제로 [RFC4646] 이전부터 폐기된 태그도 있습니다. 예를 들어 태그 "art-lojban"은 기본 언어 하위 태그 'jbo'를 위해 폐기되었습니다. 이러한 태그는 일부 하위 태그를 'variant'로 등록하여 'redundant'로 만들 수도 있었습니다. 기존 등록의 'variant- like' 하위 태그는 의미가 유사하거나 동일하더라도 앞으로 등록해서는 안 됩니다. 3.5. 하위 태그 등록 절차 현재 IANA 언어 하위 태그 레지스트리에 없는 하위 태그를 사용하려는 사람이나 이 문서에서 허용하는 범위에서 기존 레코드의 정보를 추가, 수정, 업데이트 또는 제거하려는 사람은 누구나 여기에 제시된 절차를 사용해야 합니다. 새로운 하위 태그의 독립적인 등록 대상으로는 'language' 및 'variant' 유형의 하위 태그만 고려됩니다. 안정성을 위해 필요한 Phillips & Davis 현재 최선의 관행 [41페이지]
RFC 5646 언어 태그 2009년 9월 하위 태그와 이 문서에서 정의한 제한 범위 안에서 레지스트리를 ISO 639, ISO 15924, ISO 3166 및 UN M.49와 동기화하는 데 필요한 하위 태그도 3.3절에 설명된 대로 이 절차를 사용하며, 3.4절에 설명된 안정성 규정의 적용을 받습니다. 하위 태그 레코드의 'Comments', 'Deprecated', 'Description', 'Prefix', 'Preferred-Value', 'Macrolanguage' 또는 'Suppress-Script' 필드에 관한 정보에 대한 등록 요청은 3.4절에 설명된 대로 허용됩니다. IANA 레지스트리의 그 밖의 모든 필드에 대한 변경은 허용되지 않습니다. 새 하위 태그를 등록하거나 기존 태그 또는 하위 태그의 수정을 요청하려면 요청자가 아래에 재현된 등록 양식을 작성하는 것으로 시작합니다. 요청이 등록 사항을 충분히 설명할 수 있도록 각 응답의 크기는 제한되지 않는다는 점에 유의하십시오. "요청된 레코드" 부분의 필드는 레코드가 승인되기 전에 3.1절의 요구 사항을 따라야 합니다. 언어 하위 태그 등록 양식 1. 요청자 이름: 2. 요청자의 이메일 주소: 3. 요청된 레코드: Type: Subtag: Description: Prefix: Preferred-Value: Deprecated: Suppress-Script: Macrolanguage: Comments: 4. 하위 태그의 의도된 의미: 5. 언어에 대해 출판된 설명 (책 또는 논문)의 참고 문헌: 6. 기타 관련 정보: 그림 5: 언어 하위 태그 등록 양식 작성이 완료된 등록 양식의 예는 부록 B에서 확인할 수 있습니다. 승인된 등록 양식의 전체 목록은 http://www.iana.org에서 온라인으로 확인할 수 있습니다. 독자는 Language Tag Registry가 이제 폐기되었으므로 대신 Language Subtag Registry를 찾아야 한다는 점에 유의하십시오. Phillips & Davis 현재 최선의 관행 [42페이지]
RFC 5646 언어 태그 2009년 9월 하위 태그 등록 양식은 반드시 <ietf-languages@iana.org>로 보내야 합니다. 등록 요청은 승인되어 레지스트리에 포함하기 위해 IANA에 제출되기 전에 2주간의 검토 기간을 거칩니다. 등록 절차 중 요청이 수정되는 경우(예: 3.1절의 요구 사항을 충족하도록 수정하거나 해당 레코드 유형에서 'Description' 필드를 고유하게 만드는 경우), 수정된 양식도 IANA에 제출하기 최소 1주 전에 <ietf-languages@iana.org>로 보내야 합니다. ietf-languages 목록은 공개 목록이며 <ietf-languages-request@iana.org>로 요청을 보내 가입할 수 있습니다. 이 목록은 IESG의 요청에 따라 IANA 또는 제3자가 호스팅할 수 있습니다. 등록을 IANA에 전달하기 전에 언어 하위 태그 검토자는 이 문서의 모든 요구 사항이 충족되었는지 확인해야 합니다. 여기에는 'Subtag' 필드의 값이 3.1.4절의 설명에 따라 대소문자 표기와 일치하는지, 그리고 'Description' 필드가 3.1.5절에 설명된 대로 해당 레코드 유형에서 고유한지 확인하는 것이 포함됩니다. 검토자는 또한 IANA가 레지스트리를 업데이트하는 데 도움이 되도록 적절한 File-Date 레코드가 요청에 포함되어 있는지 확인해야 합니다 (5.1절 참조). 등록 양식과 레지스트리 레코드 자체의 일부 필드에서는 비ASCII 문자를 사용할 수 있습니다. 일관성과 명확성을 위해 등록 요청에는 UTF-8 인코딩을 사용하는 것이 좋습니다. 그러나 일부 메일 클라이언트에서는 이 인코딩을 지원하지 않으므로 등록 요청에 다른 인코딩을 사용할 수도 있습니다. 언어 하위 태그 검토자는 보관된 요청 양식과 레지스트리 레코드 모두에 올바른 유니코드 문자가 나타나도록 할 책임이 있습니다. IANA에서 전사 또는 인코딩 오류가 발생한 경우 언어 하위 태그 검토자는 IANA를 돕는 데 필요한 정보를 제공하면서 레지스트리 수정을 요청합니다. 확장 언어 하위 태그('extlang' 유형)는 정의상 항상 다른 언어에 포함됩니다. 따라서 'extlang' 유형의 모든 레코드는 등록 시점에 'Prefix' 필드를 포함해야 합니다. 이 'Prefix' 필드는 절대로 변경하거나 제거할 수 없으며, 그러한 요청은 거부해야 합니다. 변형 하위 태그는 일반적으로 특정 범위의 언어 태그와 함께 사용하기 위해 등록되며, 적용 대상 언어의 용어에 기반한 변형 하위 태그가 권장됩니다. 예를 들어 하위 태그 'rozaj'(Resian)는 Resian이 슬로베니아어의 방언이므로 기본 언어 하위 태그 "sl"(슬로베니아어)로 시작하는 언어 태그와 함께 사용하도록 의도되었습니다. 따라서 하위 태그 'rozaj'는 "sl-Latn-rozaj" 또는 "sl-IT-rozaj"와 같은 태그에 적절합니다. 이 정보는 레지스트리의 'Prefix' 필드에 저장됩니다. 변형 Phillips & Davis 현재 최선의 관행 [43페이지]
RFC 5646 언어 태그 2009년 9월 등록 요청은 등록 양식에 하나 이상의 'Prefix' 필드를 포함하는 것이 좋습니다. 기존 하위 태그 값과 동일한 유형의 추가 레코드를 할당하려는 요청은 거부해야 합니다. 예를 들어 변형 하위 태그 'rozaj'는 이미 레지스트리에 존재하므로 하위 태그 'rozaj'를 가진 두 번째 'variant' 유형 레코드를 추가하는 것은 금지됩니다. 등록된 특정 변형 하위 태그의 'Prefix' 필드는 사용 지침으로 IANA 레지스트리에 존재합니다. 추가 등록 양식을 제출하여 'Prefix' 필드를 추가할 수 있습니다. 이 양식에서 "기타 관련 정보:" 필드는 접두사를 추가하는 것임을 나타내야 합니다. 다른 의미를 암시하는 'Prefix' 필드를 변형 하위 태그에 추가하려는 요청은 거부하는 것이 좋습니다. 예를 들어 "de-1994"라는 태그가 어떤 독일어 방언 또는 철자 형식을 나타내도록 하위 태그 '1994'에 접두사 "de"를 추가하려는 요청은 거부됩니다. '1994' 하위 태그는 특정 슬로베니아어 철자법을 나타내며, 이러한 추가 등록은 하위 태그에 할당된 의미를 변경하거나 모호하게 만들기 때문입니다. 대신 별도의 하위 태그를 제안하는 것이 좋습니다. 현재 'Prefix' 필드가 없는 변형 하위 태그에 'Prefix'를 추가하려는 요청은 거부해야 합니다. 접두사 없이 등록되는 변형은 많은 언어, 심지어 모든 언어에서 잠재적으로 유용하기 때문에 접두사 없이 등록됩니다. 하나 이상의 'Prefix' 필드를 추가하면 하위 태그의 범위가 크게 줄어들기 때문에 변형 사용에 잠재적으로 해로울 수 있습니다(이는 하위 태그의 범위를 넓히는 일반적인 'Prefix' 추가와 달리 안정성 규칙(3.4절)에서 허용되지 않습니다). 이러한 "접두사 없음" 변형의 예는 많은 언어를 전사하는 데 사용할 수 있는 체계인 국제 음성 기호를 나타내는 하위 태그 'fonipa'입니다. 요청에 제공되는 'Description' 필드는 라틴 문자로 작성되거나 전사된 설명을 최소 하나 포함해야 합니다. 요청에는 어떠한 문자 체계 또는 언어로 된 추가 'Description' 필드를 포함할 수도 있습니다. 'Description' 필드는 식별 목적으로 사용되며 반드시 해당 언어나 변형의 실제 고유 명칭을 나타내는 것은 아닙니다. 또한 특정 언어로 되어 있어야 하는 것도 아니지만 레코드의 항목을 식별하기에 적절하고 충분한 것이 좋습니다. 언어 하위 태그 검토자는 고유성을 보장하고 동일한 유형의 다른 레코드에 있는 'Description' 필드와의 충돌을 방지하도록 제안된 'Description' 필드를 확인하고 편집합니다. 독립적인 등록 요청에서 이러한 일이 발생하면 언어 하위 태그 검토자는 레코드를 <ietf-languages@iana.org>에 다시 제출하여 이를 Phillips & Davis 현재 최선의 관행 [44페이지]
RFC 5646 언어 태그 2009년 9월 3.5절에 설명된 논의에 따른 요청 수정으로 취급해야 합니다. 단, 요청의 유일한 목적이 중복된 'Description' 필드를 도입하는 것이라면 해당 요청을 거부해야 합니다. 'Description' 필드의 안정성은 보장되지 않습니다. 의도에 대한 수정 또는 명확화가 가능한 변경의 예입니다. 레지스트리 항목의 번역 또는 전사(정의상 새로운 정보를 제공하지 않음)를 제공하려는 시도는 승인될 가능성이 낮습니다. 2주간의 검토 기간이 지난 직후 언어 하위 태그 검토자는 다음 조치 중 하나를 수행해야 합니다. o 요청을 명시적으로 승인하고 3.3절에 설명된 절차에 따라 삽입 또는 수정할 레코드가 포함된 양식을 <iana@iana.org>로 전달합니다. o 목록에서 제기된 중대한 이의 또는 이 문서의 제약 조건 문제 (반드시 명시적으로 인용해야 함)로 인해 요청을 명시적으로 거부합니다. o 추가 논의를 허용하기 위해 검토 기간을 2주 단위로 연장합니다. 각 2주 연장 기간이 끝난 뒤 언어 하위 태그 검토자는 등록이 승인되었는지, 거부되었는지 또는 연장되었는지를 목록에 표시해야 합니다. 언어 하위 태그 검토자도 원하는 경우 목록에서 이의를 제기할 수 있다는 점에 유의하십시오. 중요한 것은 이의를 반드시 공개적으로 제기해야 한다는 것입니다. 검토 기간 중의 논의 또는 이 문서의 요구 사항으로 인해 요청을 수정해야 하는 경우가 있습니다. 신청자, 언어 하위 태그 검토자 또는 그 밖의 사람이 작성 완료된 등록 양식의 수정 버전을 제출할 수 있으며, 신청자가 명시적으로 승인하면 원래 요청 대신 이를 검토합니다. 이러한 변경으로 2주간의 논의 기간이 다시 시작되지는 않지만, IANA에 제출되는 최종 레코드를 포함하는 신청서는 언어 하위 태그 검토자가 해당 레코드를 IANA에 전달하기 최소 1주 전에 목록에 나타나야 합니다. 신청자는 거부된 신청을 더 적절하거나 추가적인 정보로 수정하여 다시 제출할 수 있으며, 이 경우 새로운 2주간의 의견 수렴 기간이 시작됩니다. 3.3절 또는 3.4절의 규정에 따라 시작된 등록은 (결국 레지스트리에 나타나야 하므로) 완전히 거부해서는 안 되며 가능한 한 신속하게 완료하는 것이 좋습니다. 검토 절차를 통해 목록 구성원은 양식의 구체적인 정보와 그 안에 포함된 레코드에 대해 의견을 제시하고 Phillips & Davis 현재 최선의 관행 [45페이지]
RFC 5646 언어 태그 2009년 9월 이를 통해 정확성과 일관성을 보장하는 데 도움을 줄 수 있습니다. 언어 하위 태그 검토자는 특정 버전의 양식을 거부할 수 있지만, 양식이 검토자의 승인을 받을 만한 형식이 되고 목록의 대략적인 합의에 부합할 때까지 위에 설명된 대로 검토 기간을 연장하면서 적절한 대체안을 제안해야 합니다. 언어 하위 태그 검토자가 내린 결정은 다른 IETF 결정 [RFC2026]과 동일한 규칙에 따라 IESG [RFC2028]에 이의를 제기할 수 있습니다. 여기에는 검토 기간을 연장하는 결정이나 결정을 명확하고 적시에 발표하지 않은 경우도 포함됩니다. 승인된 레코드는 Language Subtag Registry에 나타납니다. 승인된 등록 양식은 http://www.iana.org에서 온라인으로 확인할 수 있습니다. 기존 레코드의 업데이트 또는 변경은 새 등록과 동일한 절차를 따릅니다. 언어 하위 태그 검토자는 2주간의 검토 기간이 지난 뒤 등록을 업데이트하는 데 합의가 있는지 결정합니다. 일반적으로 원래 등록자의 이의는 이러한 합의를 형성할 때 더 큰 비중을 갖습니다. 등록은 영구적이고 안정적입니다. 일단 등록된 하위 태그는 레지스트리에서 제거되지 않으며 특정 언어 또는 변형을 지정하는 유효한 방법으로 계속 유지됩니다. 참고: 등록 양식의 "출판된 설명에 대한 참고 문헌" 부분의 목적은 언어가 등록되어 있는지 또는 특정 하위 태그가 어떤 언어나 언어 변형을 가리키는지 확인하는 데 도움을 주는 것입니다. 대부분의 경우 해당 언어의 권위 있는 문법서나 사전을 참조하는 것이 유용합니다. 그러한 자료가 존재하지 않는 경우 해당 언어를 설명하거나 해당 언어로 작성된 잘 알려진 다른 저작물이 적절할 수도 있습니다. 언어 하위 태그 검토자는 무엇이 "충분히 좋은" 참고 자료인지 결정합니다. 이 요구 사항은 화자 인구의 규모나 표준화된 철자법의 부재를 이유로 특정 언어나 방언을 제외하려는 것이 아닙니다. 소수 언어도 그 자체의 가치에 따라 동등하게 고려됩니다. 3.6. 등록 가능성 하위 태그 또는 하위 태그에 관한 정보의 등록 가능성에는 다음이 포함됩니다. o ISO 639에 나열되지 않았고 나열되거나 등록된 언어의 변형이 아닌 언어의 기본 언어 하위 태그는 등록할 수 있습니다. 이 문서가 작성된 시점에는 이러한 형태의 하위 태그 예가 없었습니다. 언어 하위 태그를 등록하려고 시도하기 전에 해당 언어를 Phillips & Davis 현재 최선의 관행 [46페이지]
RFC 5646 언어 태그 2009년 9월 ISO 639에 등록하려는 시도가 반드시 있어야 합니다. ISO 639-1, ISO 639-2 또는 ISO 639-3에 존재하는 코드로 정의된 언어, ISO 639 등록 기관에서 검토 중인 언어 또는 해당 기관에 등록을 시도한 적이 없는 언어에 대해서는 하위 태그를 등록해서는 안 됩니다. ISO 639가 이전에 어떤 언어의 등록을 거부했다면, IANA 레지스트리에 기본 언어 하위 태그로 등록되기 위해서는 필요성을 입증하는 추가적이고 매우 강력한 증거가 있어야 한다고 보는 것이 합리적입니다(이 유형의 하위 태그가 등록될 가능성은 매우 낮습니다). o 언어 내부의 방언이나 기타 구분 또는 변형, 철자법, 표기 체계, 지역적 또는 역사적 용법, 음역 또는 기타 변환, 또는 구별되는 변형은 변형 하위 태그로 등록할 수 있습니다. 예로 'rozaj' 하위 태그(슬로베니아어의 Resian 방언)가 있습니다. o 3.1절에 설명된 태그 또는 하위 태그 레코드의 필드 (일반적으로 정보 제공 성격)의 추가 또는 유지 관리가 허용됩니다. 이러한 변경에는 3.4절의 안정성 규정이 적용됩니다. 여기에는 폐기되거나 철회된 코드의 'Description', 'Comments', 'Deprecated', 'Preferred-Value' 필드, 기본 언어 하위 태그에 'Suppress-Script' 또는 'Macrolanguage' 필드를 추가하는 것, 그리고 변형 하위 태그에 적절한 'Prefix' 필드를 추가하는 것과 같이 이 문서에서 허용하는 기타 변경이 포함됩니다. o 3.4절에 설명된 대로 ISO 639, ISO 15924, ISO 3166-1 및 UN M.49의 할당을 반영하는 데 필요한 레코드 추가 및 관련 필드 값 변경이 허용됩니다. 등록을 위해 제안된 하위 태그가 기존 태그의 전체 또는 일부를 중복으로 만들지만 그 의미가 기존 태그의 의미와 충돌하거나 이를 변경하는 경우 반드시 거부해야 합니다. 이 문서는 어떤 하위 태그 또는 하위 태그 변경이 적절한지(또는 적절하지 않은지)에 대한 결정을 3.5절에 설명된 등록 절차에 맡깁니다. 참고: 네 글자 기본 언어 하위 태그는 ISO 639 표준군에 향후 alpha4 코드가 추가될 가능성에 대비해 예약되어 있습니다. ISO 639는 ISO 639의 언어 목록에 대한 추가 및 변경을 위한 등록 기관을 정의합니다. 이 기관은 다음과 같습니다. Phillips & Davis 현재 최선의 관행 [47페이지]
RFC 5646 언어 태그 2009년 9월 International Information Centre for Terminology (Infoterm) Aichholzgasse 6/12, AT-1120 Wien, Austria 전화: +43 1 26 75 35 내선 312 팩스: +43 1 216 32 72 ISO 639-2는 ISO 639-2의 언어 목록에 대한 추가 및 변경을 위한 등록 기관을 정의합니다. 이 기관은 다음과 같습니다. Library of Congress Network Development and MARC Standards Office Washington, DC 20540, USA 전화: +1 202 707 6237 팩스: +1 202 707 0115 URL: http://www.loc.gov/standards/iso639-2 ISO 639-3은 ISO 639-3의 언어 목록에 대한 추가 및 변경을 위한 등록 기관을 정의합니다. 이 기관은 다음과 같습니다. SIL International ISO 639-3 Registrar 7500 W. Camp Wisdom Rd. Dallas, TX 75236, USA 전화: +1 972 708 7400, 내선 2293 팩스: +1 972 708 7546 이메일: iso639-3@sil.org URL: http://www.sil.org/iso639-3 ISO 639-5는 ISO 639-5의 언어 목록에 대한 추가 및 변경을 위한 등록 기관을 정의합니다. 이 기관은 ISO 639-2의 기관과 동일하며 다음과 같습니다. Library of Congress Network Development and MARC Standards Office Washington, DC 20540, USA 전화: +1 202 707 6237 팩스: +1 202 707 0115 URL: http://www.loc.gov/standards/iso639-5 ISO 3166-1(국가 코드)의 유지 관리 기관은 다음과 같습니다. ISO 3166 Maintenance Agency c/o International Organization for Standardization Case postale 56 CH-1211 Geneva 20, Switzerland 전화: +41 22 749 72 33 팩스: +41 22 749 73 49 URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html Phillips & Davis 현재 최선의 관행 [48페이지]
RFC 5646 언어 태그 2009년 9월 ISO 15924(문자 체계 코드)의 등록 기관은 다음과 같습니다. Unicode Consortium Box 391476 Mountain View, CA 94039-1476, USA URL: http://www.unicode.org/iso15924 유엔 사무국 통계국은 통계용 표준 국가 또는 지역 코드를 유지 관리하며 다음 연락처로 문의할 수 있습니다. Statistical Services Branch Statistics Division United Nations, Room DC2-1620 New York, NY 10017, USA 팩스: +1-212-963-0623 이메일: statistics@un.org URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm 3.7. 확장 및 확장 레지스트리 확장 하위 태그는 'x' 이외의 단일 문자 하위 태그("singletons")로 시작되는 하위 태그입니다. 이들은 언어 구성 요소를 포함하며 언어 태그를 이해하는 애플리케이션과 호환되는 식별자를 생성하기 위해 예약됩니다. 확장의 구조와 형식은 향후 singleton을 사용하는 애플리케이션이 생성되더라도 순방향 호환되는 구현을 만들 수 있도록 이 문서에서 정의합니다. 또한 singleton을 유지 관리하는 메커니즘을 정의하면 향후 이 문서를 개정하거나 업데이트할 필요성을 줄여 이 문서의 안정성을 높일 수 있습니다. 단일 문자 하위 태그는 [RFC5226]에 정의된 "IETF Review" 정책을 사용하여 IANA가 할당합니다. 이 정책에서는 RFC 개발을 요구하며, 해당 RFC는 하위 태그를 유지 관리하기 위한 이름, 목적, 프로세스 및 절차를 정의해야 합니다. 이름, 연락 이메일, 토론 목록 이메일 및 레지스트리의 URL 위치를 포함한 유지 관리 또는 등록 기관을 RFC에 명확히 표시해야 합니다. RFC는 다음 각각을 규정하거나 포함해야 합니다. o 규격은 그 생성에 적용되는 이 문서의 특정 버전 또는 개정판을 참조해야 하며 이 문서의 이 절을 참조해야 합니다. o 규격 및 규격에서 정의하는 모든 하위 태그는 이 문서에 정의된 태그 및 하위 태그 구성에 관한 ABNF와 기타 규칙을 따라야 합니다. 특히 다음을 반드시 Phillips & Davis 현재 최선의 관행 [49페이지]
RFC 5646 언어 태그 2009년 9월 명시해야 합니다. 대소문자는 의미가 없으며 하위 태그는 길이가 8자를 초과해서는 안 됩니다. o 규격은 정규 표현을 규정해야 합니다. o 유효한 하위 태그의 규격은 인터넷을 통해 무료로 이용할 수 있어야 합니다. o 규격은 퍼블릭 도메인에 속하거나 IETF가 수용할 수 있고 RFC에 명시된 로열티 없는 라이선스로 이용할 수 있어야 합니다. o 규격에는 버전이 있어야 하며, 규격의 각 버전에는 번호와 날짜가 있어야 하고 안정적이어야 합니다. o 규격은 안정적이어야 합니다. 즉, 규격에서 한 번 정의된 확장 하위 태그는 철회되거나 의미가 실질적으로 변경되어서는 안 됩니다. o 규격은 RFC로 게시될 때 확장을 등록하는 데 사용할 이 절 아래에 재현된 등록 양식을 별도의 절에 포함해야 합니다. o 규격의 연락처 정보 및 URL 변경 사항을 IANA에 알려야 합니다. IANA는 할당된 단일 문자(singleton) 하위 태그의 레지스트리를 유지 관리합니다. 이 레지스트리는 3.1.1절의 ABNF에서 설명하는 record-jar 형식을 사용해야 합니다. 확장이 RFC로 게시되면 RFC에서 정의된 유지 관리 기관은 이 등록 양식을 <iesg@ietf.org>로 전달해야 하며, IESG는 해당 요청을 <iana@iana.org>로 전달해야 합니다. 확장의 유지 관리 기관은 내용이 변경될 때마다 제목이 "LANGUAGE TAG EXTENSION UPDATE"인 업데이트된 전체 레코드 사본을 <iana@iana.org>로 보내 레코드의 정확성을 유지해야 합니다. 이러한 업데이트에서는 'Comments', 'Contact_Email', 'Mailing_List', 'URL' 필드만 수정할 수 있습니다. 이 레코드를 유지 관리하지 않거나, 대응하는 레지스트리를 유지 관리하지 않거나, 이 문서의 이 절에서 부과하는 기타 조건을 충족하지 못하는 경우 다른 IETF 결정과 동일한 규칙에 따라 IESG [RFC2028]에 이의를 제기할 수 있으며([RFC2026] 참조), IESG가 확장 유지 관리 권한을 철회하거나 재할당할 수도 있습니다. Phillips & Davis 현재 최선의 관행 [50페이지]
RFC 5646 언어 태그 2009년 9월 %% Identifier: Description: Comments: Added: RFC: Authority: Contact_Email: Mailing_List: URL: %% 그림 6: 언어 태그 확장 레지스트리의 레코드 형식 'Identifier'에는 확장에 할당된 단일 문자 하위 태그(singleton)가 포함됩니다. 확장을 정의하기 위해 제출된 Internet-Draft는 사용할 문자 또는 숫자를 지정하는 것이 좋지만, IESG는 RFC 승인 시 할당을 변경할 수 있습니다. 'Description'에는 확장의 이름과 설명이 포함됩니다. 'Comments'는 선택적 필드이며 확장에 관한 더 폭넓은 설명을 포함할 수 있습니다. 'Added'에는 확장의 RFC가 게시된 날짜가 [RFC3339]에 규정된 "full-date" 형식으로 포함됩니다. 예: 2004-06-28은 그레고리력의 2004년 6월 28일을 나타냅니다. 'RFC'에는 확장에 할당된 RFC 번호가 포함됩니다. 'Authority'에는 확장의 유지 관리 기관 이름이 포함됩니다. 'Contact_Email'에는 유지 관리 기관에 연락할 때 사용하는 이메일 주소가 포함됩니다. 'Mailing_List'에는 유지 관리 기관에서 사용하는 메일링 리스트의 URL 또는 구독 이메일 주소가 포함됩니다. 'URL'에는 이 확장 레지스트리의 URL이 포함됩니다. Internet-Draft가 위의 조건을 충족하는지 여부의 판단과 이러한 권한을 부여하거나 보류하는 결정은 전적으로 IESG에 있으며 RFC 절차와 관련된 일반적인 검토 및 이의 제기 절차의 적용을 받습니다. 확장 작성자는 많은 처리기(올바른 형식의 처리기 대부분 포함)가 확장 하위 태그 순서에 내재된 특별한 관계 Phillips & Davis 현재 최선의 관행 [51페이지]
RFC 5646 언어 태그 2009년 9월 또는 의미를 알지 못한다는 점에 각별히 주의해야 합니다. 확장 작성자는 일치 처리나 확장이 사용되는 일반적인 프로토콜에 때때로 존재하는 길이 제한을 방해하는 하위 태그 관계 또는 정규화 메커니즘을 피하는 것이 좋습니다. 특히 애플리케이션은 일치 처리를 수행하거나 제한된 길이에 맞추기 위해 하위 태그를 잘라낼 수 있으므로, 가장 중요한 정보는 가장 중요한(가장 왼쪽의) 하위 태그에 두고 규격이 잘린 하위 태그도 원활하게 처리하도록 하는 것이 권장됩니다. 언어 태그를 특정한 알려진 프로토콜에서 사용하는 경우 해당 프로토콜이 지원하지 않는 확장을 언어 태그에 포함하지 않는 것이 권장됩니다. 또한 일부 프로토콜은 언어 태그를 저장하거나 전송하는 데 사용되는 문자열의 길이에 상한을 둘 수 있다는 점에 유의하십시오. 3.8. 언어 하위 태그 레지스트리 업데이트 이 문서가 채택된 후 IANA 언어 하위 태그 레지스트리에는 언어 태그에서 유효한 하위 태그 전체 집합이 포함되도록 업데이트가 필요했습니다. [RFC5645]는 이 업데이트를 생성하는 데 사용된 절차를 설명합니다. 이 문서가 채택될 당시 [RFC4646]에 정의된 규칙에 따라 진행 중인 등록은 이 문서에 포함된 규칙에 따라 완료해야 합니다. 3.9. 하위 태그 레지스트리의 적용 가능성 언어 하위 태그 레지스트리는 이 문서에 설명된 규칙에 따라 언어 태그를 구성하는 데 사용되는 데이터 요소의 출처입니다. 언어 태그는 텍스트뿐 아니라 비디오나 오디오와 같은 대부분의 미디어 형식을 포함한 다양한 콘텐츠의 언어적 속성을 나타내도록 설계되었습니다. 또한 여러 프로토콜 및 API에서 언어 및 로케일 협상의 기반을 구성합니다. 따라서 레지스트리는 어떤 형태로든 언어 식별이 필요한 많은 애플리케이션에 적용할 수 있지만 다음과 같은 제한이 있습니다. o 언어 선택 사용자 인터페이스를 만드는 데 사용하는 유일한 데이터 소스로 설계된 것은 아닙니다. 예를 들어 레지스트리에는 하위 태그 설명 또는 하위 태그로 구성된 태그의 번역이 포함되어 있지 않습니다. 레지스트리에 기반한 현지화 데이터의 출처는 일반적으로 제공되며, 특히 [CLDR]가 있습니다. 또한 레지스트리는 어떤 하위 태그 조합이 특히 유용하거나 관련성이 있는지도 나타내지 않습니다. Phillips & Davis 현재 최선의 관행 [52페이지]
RFC 5646 언어 태그 2009년 9월 o 서로 다른 언어 간의 관계에 관한 정보를 제공하지 않습니다. 예를 들어 사용자 인터페이스에서 언어 태그를 계층별, 지역별 또는 다른 조직 모델에 따라 선택하는 데 사용할 수 있는 정보가 이에 해당합니다. o 언어를 구성하는 것이 무엇인지에 대한 개념은 정확하지 않으므로 서로 다른 언어 태그 사이의 잠재적인 중첩에 관한 정보를 제공하지 않습니다. 동일한 콘텐츠 조각에 대해 여러 다른 언어 태그가 합리적인 선택일 수 있습니다. o 언어 협상을 수행할 때 적절한 폴백 선택에 관한 정보는 포함하지 않습니다. 좋은 폴백 언어는 지정된 언어와 언어학적으로 관련이 없을 수도 있습니다. 한 언어가 다른 언어의 폴백 언어로 자주 사용된다는 사실은 일반적으로 지리, 역사 또는 문화와 같은 외부 요인의 결과이며, 이러한 요인은 모든 경우에 적용되지 않을 수 있습니다. 예를 들어 브르타뉴어(프랑스 북서부에서 사용되는 켈트어)를 사용하는 대부분의 사람은 브르타뉴어를 사용할 수 없는 경우 프랑스어(로망스어)를 제공받는 것을 선호할 가능성이 있습니다. 4. 언어 태그의 구성 및 처리 이 절에서는 레지스트리의 정보를 태그 구문과 함께 사용하여 언어 태그를 선택하고 구성하고 처리하는 방법을 다룹니다. 4.1. 언어 태그 선택 언어 태그를 구성할 때의 기본 원칙은 "콘텐츠에 현명하게 태그를 지정하는 것"입니다. 때로는 동일한 콘텐츠에 대해 여러 가능한 태그 중 하나를 선택해야 합니다. 어떤 태그를 사용할지는 해당 콘텐츠와 애플리케이션에 따라 달라지며, 태그를 선택할 때 어느 정도 판단이 필요할 수 있습니다. 동일한 언어를 나타낼 때 동일한 언어 태그를 일관되게 사용하면 상호운용성이 가장 잘 보장됩니다. 애플리케이션의 요구 사항 때문에 여기의 규칙을 적용할 수 없다면 해당 애플리케이션은 상호운용성을 저해할 위험이 있습니다. 사용자가 언어 태그 선택에 대한 자체 규칙을 정의하지 않는 것이 강하게 권장됩니다. 이 문서를 규범적으로 참조하지만 이 절에 제시된 규칙과 다른 규칙을 적용하는 표준, 프로토콜 및 애플리케이션은 언어 태그 선택이 여기의 지침과 어떻게 다른지를 명시해야 합니다. 일관된 하위 호환성을 보장하기 위해 이 문서에는 언어 태그를 구성하는 하위 태그를 정의하는 데 사용되는 표준의 잠재적인 불안정성을 고려하는 여러 규정이 포함되어 있습니다. Phillips & Davis 현재 최선의 관행 [53페이지]
RFC 5646 언어 태그 2009년 9월 이러한 규정에 따라 유효한 언어 태그가 유효하지 않게 되는 일은 없으며, 언어 태그의 범위가 향후 더 좁아지지도 않습니다(더 넓어질 수는 있습니다). 특정 애플리케이션 또는 콘텐츠 항목에 가장 적절한 언어 태그는 시간이 지나면서 달라질 수 있지만, 한 번 적용된 태그 자체가 유효하지 않게 되거나 그 의미가 완전히 변경될 수는 없습니다. 하위 태그는 태그에 유용한 구별 정보를 추가할 때만 사용하는 것이 좋습니다. 불필요한 하위 태그는 언어 태그의 의미, 이해 및 처리를 방해합니다. 특히 사용자와 구현은 레지스트리의 'Prefix' 및 'Suppress-Script' 필드(3.1절에서 정의)를 따르는 것이 좋습니다. 이러한 필드는 특정 추가 하위 태그를 언어 태그에서 언제 사용하거나 피해야 하는지에 관한 지침을 제공합니다. 언어 태그를 구성하는 데 사용되는 하위 태그의 선택은 다음 지침을 따르는 것이 좋습니다. 1. 가능한 한 정밀한 태그를 사용하되, 정당화할 수 있는 것보다 더 구체적으로 만들지는 마십시오. 애플리케이션에서 콘텐츠를 구별하는 데 중요하지 않은 하위 태그를 사용하지 마십시오. * 예를 들어 독일어로 작성된 이메일에 태그를 지정할 때는 'de'로 충분할 수 있으며, "de-CH-1996"은 이러한 작업에는 불필요하게 정밀할 가능성이 높습니다. * 일부 하위 태그 시퀀스는 일반 사용자가 예상하는 언어를 나타내지 않을 수도 있다는 점에 유의하십시오. 예를 들어 스위스 독일어(Schweizerdeutsch)는 "de-CH"가 아니라 "gsw-CH"로 나타냅니다. 후자의 태그는 스위스('CH')에서 사용되는 독일어('de'), 즉 스위스 표준 독일어 (Schweizer Hochdeutsch)를 나타냅니다. 둘 다 실제 언어이며, 애플리케이션에서 이를 구별하는 것이 중요할 수 있습니다. 2. 문자 체계 하위 태그가 태그에 구별 정보를 추가하지 않는 한 언어 태그를 구성할 때 문자 체계 하위 태그를 사용하지 않는 것이 좋습니다. 문자 체계 하위 태그는 [RFC4646]에서 처음 공식적으로 정의되었습니다. 이러한 하위 태그는 기본 언어와 지역 하위 태그 사이에 나타나므로 이 문서에서 폐기한 [RFC1766] 또는 [RFC3066] 구현에서 일치 처리와 하위 태그 식별에 영향을 줄 수 있습니다. 특정 상황에서 일관되게 사용하는 한 일부 애플리케이션은 언어 태그에서 문자 체계 하위 태그를 사용함으로써 이점을 얻을 수 있습니다. 문자 체계 하위 태그는 오디오 녹음과 같이 문자로 작성되지 않은 콘텐츠에는 절대로 적절하지 않습니다. 레지스트리의 기본 또는 확장 언어 레코드에 있는 'Suppress-Script' 필드는 대부분의 애플리케이션에서 구별 정보를 추가하지 않는 문자 체계 하위 태그를 나타냅니다. 이 필드는 Phillips & Davis 현재 최선의 관행 [54페이지]
RFC 5646 언어 태그 2009년 9월 사용자가 특정 기본 언어 하위 태그와 함께 문자 체계 하위 태그를 포함하지 않는 것이 좋은 경우를 정의합니다. 예를 들어 구현이 Basic Filtering [RFC4647](원래 [RFC2616]의 14.4절에 설명됨)을 사용하여 콘텐츠를 선택하고 사용자가 언어 범위 "en-US"를 요청했다면 "en-Latn-US"로 표시된 콘텐츠는 요청과 일치하지 않으므로 선택되지 않습니다. 따라서 문자 체계 하위 태그를 일반적으로 언제 사용하고 언제 사용하지 않아야 하는지 아는 것이 중요합니다. 예를 들면 다음과 같습니다. * 거의 모든 영어 문서는 라틴 문자로 작성되며 구별 정보를 추가하지 않으므로 하위 태그 'Latn'은 기본 언어 'en'과 함께 사용하지 않는 것이 좋습니다. 그러나 문서가 영어로 작성되면서 라틴 문자와 점자('Brai') 같은 다른 문자 체계를 함께 사용한다면 스타일시트 적용과 같은 콘텐츠 선택을 돕기 위해 두 문자 체계를 모두 나타내는 것이 적절할 수 있습니다. * 인간 음성 녹음과 같이 문자로 작성되지 않은 콘텐츠에 태그를 지정할 때는 해당 언어가 일반적으로 여러 문자 체계로 작성되는 경우에도 문자 체계 하위 태그를 사용하지 않는 것이 좋습니다. 따라서 영화의 자막에는 "uz-Arab"(우즈베크어, 아랍 문자) 태그를 사용할 수 있지만 동일한 언어의 오디오 트랙에는 단순히 "uz" 태그를 지정합니다. (콘텐츠가 문자로 작성되지 않은 경우 'Zxxx' 하위 태그가 "문자로 작성되지 않은 문서용 코드"를 나타내므로 "uz-Zxxx" 태그를 사용할 수도 있습니다.) 3. 태그 또는 하위 태그의 레지스트리 항목에 'Preferred-Value' 필드가 있으면 선호 값이 나타나는 태그 또는 하위 태그보다 해당 필드의 값을 사용하여 언어 태그를 구성하는 것이 좋습니다. * 예를 들어 Lojban에는 기존 태그 "art-lojban"보다 'jbo'를 사용하는 것이 좋습니다. 4. 언어 집합의 하위 태그보다 개별 언어의 하위 태그 또는 하위 태그 시퀀스를 우선해서 사용하십시오. "언어 집합"은 공통 조상에서 유래했거나 동일한 지리적 지역에서 사용되거나 그 밖의 방식으로 관련된 언어 그룹입니다. 특정 언어 집합에는 [ISO639-5]에서 코드를 할당합니다(그리고 이러한 [ISO639-5] 코드 중 일부는 [ISO639-2]에서도 집합으로 정의됩니다). 이러한 코드는 레지스트리에 기본 언어 하위 태그로 포함됩니다. 레지스트리에서 언어 집합을 나타내는 하위 태그에는 값이 'collection'인 'Scope' 필드가 있습니다. 언어 집합의 하위 태그는 Phillips & Davis 현재 최선의 관행 [55페이지]
RFC 5646 언어 태그 2009년 9월 항상 'mul' 및 'und'(아래 참조)와 같이 덜 구체적인 대안보다 우선되며, 더 구체적인 언어 정보를 사용할 수 없는 경우 언어 집합을 나타내는 하위 태그를 사용할 수 있습니다. 그러나 대부분의 사용자와 구현은 해당 집합과 그 개별 언어 사이에 관계가 있다는 사실을 알지 못합니다. 또한 집합 내 개별 언어 사이의 관계는 명확하게 정의되어 있지 않습니다. 특히 이러한 언어는 일반적으로 상호 이해가 가능하지 않습니다. 하위 태그가 서로 다르므로 집합에 대한 요청은 일반적으로 집합에 포함된 개별 언어 하위 태그로 지정된 항목이 아니라 집합의 하위 태그로 지정된 항목만 반환합니다. * 예를 들어 집합은 포함 관계로 해석되므로 하위 태그 'gem'(게르만어족)은 "en"(영어), "de"(독일어), 또는 "gsw"(스위스 독일어, 알레만어)로 태그를 지정하는 것이 더 적절한 콘텐츠에 사용할 수도 있지만 사용하지 않는 것이 좋습니다. 'gem'은 이러한 언어(및 다른 언어)를 모두 포함하지만 대부분의 구현은 'gem'을 개별 언어와 일치시키지 않습니다. 따라서 이 하위 태그를 사용하면 원하는 결과를 얻지 못합니다. 5. [ISO639-2]는 언어 태그를 선택할 때 추가적인 주의가 필요한, 하위 태그 레지스트리에 포함된 여러 코드를 정의했습니다. 이러한 경우 대부분은 언어 태그 생략이 허용된다면 해당 코드를 사용하는 것보다 생략하는 것이 좋습니다. 추가 정보가 애플리케이션에 어떤 가치를 전달하지 않는 한 언어 태그에 이러한 하위 태그를 접두사로 포함하지 않는 것이 좋습니다. * 'mul'(Multiple) 기본 언어 하위 태그는 여러 언어로 된 콘텐츠를 식별합니다. 각 콘텐츠 요소에 대해 언어 목록이나 개별 태그를 대신 사용할 수 있다면 이 하위 태그를 사용하지 않는 것이 좋습니다. 예를 들어 'Content- Language' 헤더 [RFC3282]에서는 하나의 언어 태그만이 아니라 언어 목록을 사용할 수 있습니다. * 'und'(Undetermined) 기본 언어 하위 태그는 언어가 결정되지 않은 언어적 콘텐츠를 식별합니다. 언어 태그가 필요하지만 언어 정보를 사용할 수 없거나 결정할 수 없는 경우가 아니라면 이 하위 태그를 사용하지 않는 것이 좋습니다. 허용되는 경우 언어 태그를 생략하는 것이 더 좋습니다. 'und' 하위 태그는 언어 태그를 반드시 제공해야 하는 프로토콜이나 기본 언어 하위 태그가 필요한 경우(예: "und-Latn")에 유용할 수 있습니다. 특정 상황에서 언어 태그를 일치시킬 때도 'und' 하위 태그가 유용할 수 있습니다. Phillips & Davis 현재 최선의 관행 [56페이지]
RFC 5646 언어 태그 2009년 9월 * 'zxx'(Non-Linguistic, Not Applicable) 기본 언어 하위 태그는 언어 분류가 부적절하거나 적용되지 않는 콘텐츠를 식별합니다. 예로 기악 또는 전자 음악, 비언어적 소리로 구성된 녹음, 내레이션·대화·인쇄된 제목·자막이 없는 시청각 자료, 기계어 또는 문자 코드로 구성된 기계 판독 가능 데이터 파일, 또는 프로그래밍 소스 코드 등이 있습니다. * 'mis'(Uncoded) 기본 언어 하위 태그는 언어는 알려져 있지만 현재 대응하는 하위 태그가 없는 콘텐츠를 식별합니다. 이 하위 태그는 사용하지 않는 것이 좋습니다. 향후 다른 코드가 추가되면 그 적용이 유효하지 않게 될 수 있으므로 본질적으로 불안정하며 따라서 BCP 47의 안정성 목표와 호환되지 않습니다. 다른 하위 태그, 즉 'und' 또는 (사전 합의가 있는 경우) 사적 사용 하위 태그를 사용하는 것이 항상 더 좋습니다. 6. 변형 하위 태그는 필요한 경우에만 올바른 순서로 사용하십시오. 대부분의 변형 하위 태그에는 적절하게 함께 사용할 수 있는 하위 태그 목록을 나타내는 하나 이상의 'Prefix' 필드가 레지스트리에 있습니다. 변형은 이러한 'Prefix' 필드 중 하나에 나타나는 하위 태그와 함께만 사용하는 것이 좋습니다. 변형의 'Prefix' 필드 중 하나에 두 번째 변형이 나열되어 있다면, 두 변형이 모두 나타나는 모든 언어 태그에서 첫 번째 변형은 두 번째 변형 바로 뒤에 나타나는 것이 좋습니다. 범용 변형('Prefix' 필드가 전혀 없는 변형)은 다른 모든 변형 하위 태그 뒤에 나타나는 것이 좋습니다. 나머지 변형은 가장 중요한 하위 태그를 먼저 배치하여 정렬하십시오. 어느 하위 태그도 더 중요하지 않거나 관계를 결정할 수 없다면 하위 태그를 알파벳순으로 정렬하십시오. 변형은 매우 특수하므로 많은 변형을 함께 사용하면 일반적으로 태그가 지나치게 좁아져 추가된 정밀성의 이점을 상쇄합니다. 하위 태그를 다른 순서로 배치하면 상호운용성과 태그의 전반적인 해석을 방해합니다. 예를 들면 다음과 같습니다. * 태그 "en-scotland-fonipa"(영어, 스코틀랜드 방언, IPA 음성 전사)는 'scotland'에 "en"이라는 'Prefix'가 있고, 'fonipa'에는 'Prefix' 필드가 없으므로 올바른 순서입니다. * 태그 "sl-IT-rozaj-biske-1994"는 올바른 순서입니다. 'rozaj'는 유일한 'Prefix'로 "sl"을 나열하고, 'biske'는 유일한 'Prefix'로 "sl-rozaj"를 나열합니다. 하위 태그 '1994'에는 여러 접두사가 있으며, Phillips & Davis 현재 최선의 관행 [57페이지]
RFC 5646 언어 태그 2009년 9월 그중에는 "sl-rozaj"도 있습니다. 그러나 'Prefix' 필드 중 하나가 "sl-rozaj- biske"이므로 'rozaj'와 'biske' 모두의 뒤에 나타납니다. 7. 기존 태그 "i-default"(Default Language)는 원래 [RFC1766]에 따라 [RFC2277]의 요구를 충족하기 위해 등록되었습니다. 이는 특정 언어를 나타내는 데 사용되는 것이 아니라 사용자의 언어 기본 설정을 확정할 수 없을 때 사용되는 조건 또는 콘텐츠를 식별하기 위한 것입니다. 기본 언어 콘텐츠를 해당 특정 태그로 표시해야 하는 애플리케이션이나 프로토콜의 기본 콘텐츠를 표시하는 수단을 제외하고는 사용하지 않는 것이 좋습니다. 애플리케이션 또는 프로토콜에서 기본 언어 콘텐츠가 반환되고 있는 경우를 식별하는 데 사용할 수도 있습니다. 4.1.1. 포괄 언어에 태그 지정 레지스트리의 일부 기본 언어 레코드에는 각 "포괄 언어"에서 해당 대언어로의 매핑을 포함하는 'Macrolanguage' 필드(3.1.10절)가 있습니다. 'Macrolanguage' 매핑은 포괄 언어와 그 대언어 사이의 관계가 무엇인지 정의하지 않으며, 동일한 대언어에 포함된 언어들이 서로 어떤 관계에 있는지도 정의하지 않습니다. 동일한 대언어에 포함된 두 서로 다른 언어는 예를 들어 프랑스어와 스페인어보다도 서로 더 다를 수 있습니다. 중국어('zh') 및 아랍어('ar')와 같은 일부 특정 대언어는 다르게 처리됩니다. 4.1.2절을 참조하십시오. 더 구체적인 포괄 언어 하위 태그를 사용하여 언어 태그를 구성하는 것이 좋지만, 대언어의 기본 언어 하위 태그 또는 포괄 언어의 하위 태그 중 어느 쪽을 사용해도 됩니다. 예를 들어 이는 Plains Cree를 'cr'(Cree)이 아니라 'crk'로 태그하는 것을 의미합니다. 각 대언어 하위 태그의 범위는 정의상 모든 포괄 언어를 포함합니다. 포괄 언어 사이의 관계는 다양하므로 사용자는 대언어 하위 태그가 특정 포괄 언어를 의미한다고 가정할 수 없으며, 특정한 두 포괄 언어가 상호 이해 가능하거나 그 밖의 방식으로 서로 바꾸어 사용할 수 있다고 가정할 수도 없습니다. 애플리케이션은 일치 처리 또는 언어 협상을 개선하기 위해 대언어 정보를 사용할 수 있습니다. 예를 들어 'sr'(세르비아어)과 'hr'(크로아티아어)이 하나의 대언어를 공유한다는 정보는 예를 들어 'sr'(세르비아어)과 'ma'(마케도니아어) 사이보다 이들 언어 사이에 더 가까운 관계가 있음을 나타냅니다. 그러나 이러한 관계가 보장되는 것도 아니며 배타적인 것도 아닙니다. 예를 들어 루마니아어('ro')와 Phillips & Davis 현재 최선의 관행 [58페이지]
RFC 5646 언어 태그 2009년 9월 몰도바어('mo')는 대언어를 공유하지 않지만, 하나의 대언어를 공유하는 광둥어('yue')와 우어('wuu')보다 서로 훨씬 더 밀접한 관계가 있습니다. 4.1.2. 확장 언어 하위 태그 사용 이 문서가 채택되기 전에 사용된 언어 태그 형식을 수용하기 위해 언어 태그는 특별한 호환성 메커니즘인 확장 언어 하위 태그를 제공합니다. 일부 언어에는 기본 및 확장 언어 하위 태그가 모두 제공되었습니다. 여기에는 대언어와 일반적으로 동의어로 간주되는 특정한 지배적 변종이 있는 말레이어('ms') 및 우즈베크어('uz')와 같은 대언어가 포함됩니다. 중국어('zh') 및 아랍어('ar') 대언어와 여러 수어('sgn') 같은 다른 언어는 전통적으로 해당 언어를 나타내기 위해 기본 언어 하위 태그를 여러 지역 하위 태그와 결합하거나 등록된 기존 태그의 일부로 사용해 왔습니다. 이 문서의 채택으로 이러한 다양한 언어 계통 또는 그룹에 포함된 언어를 식별하기 위한 특정 ISO 639-3 하위 태그를 사용할 수 있게 되었습니다. 이에 따라 이전에는 없었던 언어 태그 선택지가 생겼습니다. o 각 포괄 언어의 하위 태그를 기본 언어 하위 태그로 사용하는 것이 좋습니다. 예를 들어 관화로 된 문서에는 "zh"(중국어)보다 "cmn"(관화의 하위 태그)으로 태그를 지정하는 것이 좋습니다. o 호환성이 필요하거나 바람직한 경우 포괄 하위 태그를 확장 언어 하위 태그로 사용할 수 있습니다. 예를 들어 관화 문서에는 "cmn" 또는 "zh" 대신 "zh-cmn"으로 태그를 지정할 수 있습니다. o 더 구체적인 포괄 언어 하위 태그 대신 대언어 또는 접두사 역할을 하는 하위 태그를 사용하여 태그를 구성할 수도 있습니다. 즉, "zh-HK" 또는 "sgn-RU"와 같은 태그도 여전히 유효합니다. 중국어('zh')는 이를 잘 보여주는 예입니다. 과거에는 여러 콘텐츠에서 'zh' 하위 태그로 시작하는 태그를 사용하면서 지역 코드, 사적 사용 시퀀스 또는 등록된 기존 값에 애플리케이션별 의미를 연결했습니다. 이는 역사적으로 언어 태그를 구성하는 데 대언어 하위 태그 'zh'만 사용할 수 있었기 때문입니다. 그러나 중국어 하위 태그 'zh'에 포함되는 언어는 대체로 음성으로 사용될 때 서로 이해할 수 없으며, 이러한 언어의 표기 형식도 형태와 용법에서 큰 차이를 보입니다. Phillips & Davis 현재 최선의 관행 [59페이지]
RFC 5646 언어 태그 2009년 9월 호환성을 제공하기 위해 'zh' 하위 태그에 포함되는 중국어 계열 언어는 레지스트리에 기본 언어 하위 태그와 확장 언어 하위 태그 모두로 등록되어 있습니다. 예를 들어 광둥어의 ISO 639-3 코드는 'yue'입니다. 광둥어 콘텐츠에는 역사적으로 "zh-HK"와 같은 태그를 사용했을 수 있습니다(광둥어가 홍콩에서 일반적으로 사용되기 때문입니다). 그러나 이 태그는 실제로 홍콩에서 사용되는 모든 종류의 중국어를 의미합니다. 레지스트리에서 ISO 639-3 코드를 사용할 수 있게 됨에 따라 광둥어 콘텐츠에는 'yue' 하위 태그를 사용하여 직접 태그를 지정할 수 있습니다. 콘텐츠에서는 "yue-HK"(광둥어, 홍콩)와 같이 이를 기본 언어 하위 태그로 사용할 수 있습니다. 또는 "zh-yue-Hant"(중국어, 광둥어, 번체 문자)와 같이 'zh'와 함께 확장 언어 하위 태그를 사용할 수 있습니다. 위에서 설명했듯이 애플리케이션은 더 구체적인 포괄 언어 하위 태그를 사용하는 대신 대언어 하위 태그를 사용하여 태그를 구성할 수 있습니다. 예를 들어 이미 'zh'(중국어) 하위 태그를 사용한 태그로 많은 데이터를 보유한 애플리케이션은 콘텐츠에 'cmn' (관화), 'yue'(광둥어), 'wuu'(우어) 등을 사용하여 더 정확하게 태그를 지정할 수 있더라도 새 데이터에도 이보다 일반적인 하위 태그를 계속 사용할 수 있습니다. 마찬가지로 이미 'ar'(아랍어) 하위 태그로 시작하는 태그를 사용하는 애플리케이션은 새 데이터에 'arb'(표준 아랍어)를 사용하여 더 정확하게 태그를 지정할 수 있더라도 이보다 일반적인 하위 태그를 계속 사용할 수 있습니다. 어떤 경우에는 포괄 언어에 대해 RFC 3066 시대에 태그가 등록된 경우가 있습니다. 아직 폐기되거나 중복으로 전환되지 않은 이러한 기존 태그는 이 문서가 채택될 때 레지스트리에서 폐기되었습니다. 기존 값이므로 계속 유효하게 사용할 수 있으며 일부 콘텐츠나 애플리케이션에서 이를 사용할 수도 있습니다. 다른 기존 태그와 마찬가지로 구현이 기존 태그를 이 문서에서 권장하는 대응하는 포괄 언어 하위 태그와 연결하지 못할 수 있으므로 비교를 위해 태그를 정규화하는 것이 권장됩니다. 이에 해당하는 예로 "zh-hakka" (하카어) 및 "zh-guoyu"(관화 또는 표준 중국어) 태그가 있습니다. 수어는 언어적 계통이 아니라 의사소통 방식을 공유합니다. 독립적으로 발전한 수많은 수어가 있으며, 하위 태그 'sgn'은 수어가 존재한다는 사실만 나타냅니다. 여러 수어는 RFC 3066 시대에 기존 태그도 등록되었습니다. 예를 들어 기존 태그 "sgn-US"는 미국이라는 지역을 참조하지 않고 특별히 'American Sign Language'를 나타내도록 등록되었습니다. 이 태그는 여전히 유효하지만 폐기되었습니다. 미국 수어로 된 문서에는 "ase" 또는 "sgn-ase" 중 하나를 사용할 수 있습니다('ase' 하위 태그는 'American Sign Language'라는 언어를 나타냅니다). Phillips & Davis 현재 최선의 관행 [60페이지]
RFC 5646 언어 태그 2009년 9월 4.2. 언어 태그의 의미 언어 태그의 의미는 그 안에 포함된 하위 태그의 의미와 관련됩니다. 각 하위 태그는 관련 콘텐츠에 대해 기대할 수 있는 일정한 범위를 암시하지만 이를 보장하지는 않습니다. 예를 들어 'Arab'(아랍 문자) 같은 문자 체계 하위 태그를 사용한다고 해서 콘텐츠에 아랍 문자만 포함되어 있다는 의미는 아닙니다. 이는 관련 언어가 주로 아랍 문자로 작성된다는 의미입니다. 따라서 언어 태그와 그 하위 태그는 매우 넓은 범위의 변형을 포괄하면서도 각각의 특정 사례에서 여전히 적절할 수 있습니다. 태그의 유효성만이 그 유용성을 결정하는 유일한 요소는 아닙니다. 모든 유효한 태그에는 의미가 있지만 실제 세계의 언어 사용을 나타내지 않을 수도 있습니다. 하위 태그를 자유롭게 조합할 수 있는 시스템에서는 이를 피할 수 없습니다. 예를 들어 "ar-Cyrl-CO" (아랍어, 키릴 문자, 콜롬비아에서 사용됨) 또는 "tlh- Kore-AQ-fonipa"(클링온어, 한글, 남극에서 사용됨, IPA 음성 전사) 같은 태그는 모두 유효하지만 유용한 언어 속성 조합을 나타낼 가능성은 낮습니다. 특정 태그의 의미는 태그가 나타나는 문맥에 의존하지 않습니다. 그러나 태그의 의미와 해당 태그가 적용되는 정보 객체 사이의 관계는 달라질 수 있습니다. o 하나의 정보 객체에서는 연결된 언어 태그를 전체 객체를 완전히 이해하는 데 필요한 언어 집합으로 해석할 수 있습니다. 예: 일반 텍스트 문서. o 정보 객체의 집합에서는 연결된 언어 태그를 해당 집합의 구성 요소 안에서 사용되는 언어 집합으로 간주할 수 있습니다. 예: 문서 저장소 및 라이브러리. o 대안을 제공하는 것이 목적인 정보 객체에서는 연결된 언어 태그를 콘텐츠가 여러 언어로 제공되며 그 언어를 찾으려면 각 대안을 확인해야 한다는 힌트로 간주할 수 있습니다. 이 경우 여러 태그가 있다는 사실이 문서를 완전히 이해하기 위해 여러 언어를 알아야 한다는 의미는 아닐 수 있습니다. 예: MIME multipart/ alternative [RFC2046]. o HTML 및 XML과 같은 마크업 언어에서는 마크업 구조로 식별되는 문서의 각 부분(전체 문서 자체 포함)에 언어 정보를 추가할 수 있습니다. 예를 들어 독일어 문서 안에 <span lang="fr">C'est la vie.</span>를 작성할 수 있습니다. 그러면 독일어 사용자는 프랑스어- Phillips & Davis 현재 최선의 관행 [61페이지]
RFC 5646 언어 태그 2009년 9월 독일어 사전을 이용해 표시된 부분의 의미를 확인할 수 있습니다. 사용자가 음성 합성 인터페이스를 통해 해당 문서를 듣고 있다면 이 구성을 사용하여 합성기에 부적절한 독일어 규칙 대신 해당 텍스트 범위에 적절한 프랑스어 텍스트 음성 변환 발음 규칙을 적용하도록 알릴 수 있습니다. o 독자를 식별할 수 있는 마크업 언어 및 문서 형식에서는 언어 태그가 해당 문서에 적합한 독자를 나타낼 수 있습니다. 예를 들어 앞 항목에서 설명한 동일한 HTML 문서에는 파일의 의도된 독자가 독일어 사용자임을 나타내기 위해 HTTP 헤더 "Content-Language: de"가 있을 수 있습니다(문서 안에 세 단어가 프랑스어로 나타나며 그렇게 식별되어 있더라도 마찬가지입니다). o 시스템 및 API에서 언어 태그는 대부분의 로케일 식별자 구현의 기반을 구성합니다. 예를 들어 유니코드의 CLDR(Common Locale Data Repository)(UTS #35 [UTS35] 참조) 프로젝트를 참조하십시오. 언어 태그는 유사한 하위 태그 시퀀스를 포함할 때 서로 관련됩니다. 예를 들어 언어 태그 B가 언어 태그 A를 접두사로 포함한다면 B는 일반적으로 A보다 "더 좁거나" "더 구체적"입니다. 따라서 "zh-Hant-TW"는 "zh-Hant"보다 더 구체적입니다. 이 관계가 모든 경우에 보장되는 것은 아닙니다. 특히 동일한 하위 태그 시퀀스로 시작하는 언어가 서로 이해 가능하다고 보장되지는 않지만 실제로 가능할 수도 있습니다. 예를 들어 태그 "az"는 "az-Latn"(라틴 문자로 작성된 아제르바이잔어)과 "az-Cyrl" (키릴 문자로 작성된 아제르바이잔어) 모두와 접두사를 공유합니다. 두 텍스트를 소리 내어 읽었을 때 들리는 언어적 내용은 같을 수 있지만 한 문자 체계를 능숙하게 읽는 사람이 다른 문자 체계를 읽지 못할 수도 있습니다. "az"로 태그된 콘텐츠는 대부분 하나의 문자 체계로만 작성되어 있으므로 다른 문자 체계에 익숙한 독자는 이해하지 못할 수도 있습니다. 마찬가지로 모든 하위 태그가 실제 언어적 차이를 지정하는 것은 아닙니다. 예를 들어 태그 "en-US"와 "en-CA"는 각각 대략 미국과 캐나다의 특징으로 일반적으로 여겨지는 특성을 가진 영어를 의미합니다. 미국에서 임의로 선택한 한 지점과 캐나다에서 임의로 선택한 한 지점 사이에 중요한 방언 경계가 존재한다는 의미는 아닙니다. 또한 특정 지역 하위 태그가 해당 지역 안에는 언어적 차이가 존재하지 않는다는 의미도 아닙니다. Phillips & Davis 현재 최선의 관행 [62페이지]
RFC 5646 언어 태그 2009년 9월 4.3. 언어 목록 일부 애플리케이션에서는 하나의 콘텐츠 항목을 둘 이상의 언어 태그와 연결하는 것이 가장 적절할 수 있습니다. 이러한 사용의 예는 다음과 같습니다. o 여러 개의 서로 다른 변종이 포함된 콘텐츠 항목. 여러 선택이 적절할 수 있는 경우 해당 콘텐츠 항목에 적합한 독자를 나타내기 위해 자주 사용됩니다. 그 예는 다음과 같습니다. * 영화 제목의 적절한 독자에 관한 메타데이터. 예를 들어 DVD에서 개별 오디오 트랙에 'de'(독일어), 'fr'(프랑스어), 'es'(스페인어)로 표시하면서 전체 제목의 전체 독자로 "de, fr, es"를 나열할 수 있습니다. * 프랑스어/영어, 영어/프랑스어 사전에 "en"과 "fr"을 모두 태그하여 프랑스어와 영어에 동등하게 적용됨을 나타냅니다. * 라틴어나 그리스어 고전 저작물에서 일반적으로 볼 수 있는 문서의 병렬 또는 행간 번역. o 하나의 언어를 포함하지만 여러 수준의 구체성이 필요한 콘텐츠 항목. 예를 들어 라이브러리는 특정 저작물을 노르웨이어('no')와 뉘노르스크('nn') 모두로 분류하여 그 차이를 이해하거나 콘텐츠를 더 좁게 선택해야 하는 독자에게 제공하려 할 수 있습니다. 4.4. 길이 고려 사항 언어 태그의 크기에는 정의된 상한이 없습니다. 역사적으로 대부분의 언어 태그는 언어 및 지역 하위 태그로 구성되어 총 길이가 최대 6자였지만, 더 큰 태그도 항상 가능했고 실제로 사용되어 왔습니다. 언어 태그 구문이나 이 문서의 다른 요구 사항은 언어 태그의 하위 태그 수(따라서 태그 크기의 상한)에 고정된 상한을 부과하지 않습니다. 언어 태그 구문은 특정 언어에 따라 일부 애플리케이션에서 언어를 완전히 식별하려면 더 많은 하위 태그(따라서 더 긴 태그)가 필요한 경우도 있음을 보여줍니다. 따라서 길거나 복잡한 하위 태그 시퀀스를 생각할 수 있습니다. Phillips & Davis 현재 최선의 관행 [63페이지]
RFC 5646 언어 태그 2009년 9월 4.4.1. 제한된 버퍼 크기에서의 작업 일부 애플리케이션과 프로토콜은 고정 버퍼 크기를 할당하거나 언어 태그의 길이를 다른 방식으로 제한해야 합니다. 적합한 구현이나 규격은 지정된 길이를 초과하는 언어 태그의 저장을 지원하지 않을 수 있습니다. 이러한 제한은 모두 명확하게 문서화하는 것이 좋으며, 해당 문서에는 더 긴 태그가 어떻게 처리되는지(예: 오류 값이 생성되는지 또는 언어 태그가 잘리는지)도 포함하는 것이 좋습니다. 임의의 제한에서 태그를 자르도록 허용하면서 그 제한이 무엇인지 아무런 표시도 하지 않는 프로토콜은 태그의 의미를 크게 변경하여 문제를 일으킬 가능성이 있습니다. 실제로 대부분의 언어 태그에는 몇 개의 하위 태그만 필요하며 합리적인 크기의 버퍼 제한에 근접하지 않습니다. 4.1절을 참조하십시오. 일부 규격이나 프로토콜은 태그 길이에 제한이 있지만 고정된 길이 제한은 없습니다. 예를 들어 [RFC2231]에는 명시적인 길이 제한이 없습니다. 언어 태그에 사용할 수 있는 길이는 다른 헤더 구성 요소 (예: charset 이름)의 길이와 [RFC2047]의 76자 제한을 함께 고려하여 제한됩니다. 따라서 "제한"은 50자 이상일 수도 있지만 매우 작을 가능성도 있습니다. 버퍼 제한을 할당할 때의 고려 사항은 다음과 같습니다. 구현은 태그의 의미를 의도적으로 변경하는 경우 또는 프로토콜에서 저장이나 전송을 위해 지정한 제한된 버퍼 크기에 태그가 들어가지 않는 경우가 아니라면 언어 태그를 자르지 않는 것이 좋습니다. 태그를 자르면 의미가 변경되므로 구현은 태그가 잘릴 때 사용자에게 경고하는 것이 좋습니다. 공간이 제한되어 있지만 고정된 제한은 없는 프로토콜 또는 규격의 구현은 태그를 자르는 대신 가능한 가장 긴 태그를 사용하는 것이 좋습니다. 언어 태그에 제한된 버퍼 크기를 지정하는 프로토콜이나 규격은 최소 35자의 언어 태그를 허용해야 합니다. [RFC4646]에서는 'extlang' 생성 규칙의 세 요소를 모두 포함했기 때문에 최소 필드 크기로 42자를 권장했다는 점에 유의하십시오. 그중 두 요소는 이제 영구적으로 예약되었으므로 최대 길이인 8자의 등록된 기본 언어 하위 태그가 이제 가장 긴 language-extlang 조합보다 더 깁니다. 확장 또는 사적 사용 하위 태그를 일반적으로 사용하는 Phillips & Davis 현재 최선의 관행 [64페이지]
RFC 5646 언어 태그 2009년 9월 프로토콜이나 규격에서는 더 긴 "최소 버퍼" 크기를 예약하거나 권장할 수 있습니다. 다음 예시는 35자 권장 사항이 어떻게 도출되었는지 보여줍니다. language = 8 ; 허용되는 가장 긴 등록 값 ; primary+extlang보다 김 ; 이는 7자가 필요함 script = 5 ; 억제되지 않은 경우: 4.1절 참조 region = 4 ; UN M.49 숫자 지역 코드 ; ISO 3166-1 코드는 3자가 필요함 variant1 = 9 ; 접두사로 'language'가 필요함 variant2 = 9 ; 매우 드물며, ; 접두사로 'language-variant1'이 필요함 total = 35자 그림 7: 태그 길이 제한의 도출 4.4.2. 언어 태그 자르기 언어 태그를 자르면 태그의 의미가 변경되므로 피하는 것이 좋습니다. 그러나 제한된 버퍼 크기 때문에 언어 태그를 잘라야 하는 경우가 있습니다. 이러한 자르기는 하위 태그를 중간에서 잘라내거나 유효하지 않은 태그(예: "-" 문자로 끝나는 태그)를 생성하도록 허용해서는 안 됩니다. 이는 태그를 자르는 애플리케이션이나 프로토콜이 언어 태그의 오른쪽에서 앞에 있는 "-"와 함께 하위 태그를 점진적으로 제거하여 주어진 버퍼에 충분히 들어갈 만큼 태그가 짧아질 때까지 반복해야 함을 의미합니다. 결과 태그가 단일 문자 하위 태그로 끝나는 경우 해당 하위 태그와 앞의 "-"도 제거해야 합니다. 예를 들면 다음과 같습니다. 자를 태그: zh-Latn-CN-variant1-a-extend1-x-wadegile-private1 1. zh-Latn-CN-variant1-a-extend1-x-wadegile 2. zh-Latn-CN-variant1-a-extend1 3. zh-Latn-CN-variant1 4. zh-Latn-CN 5. zh-Latn 6. zh 그림 8: 태그 자르기의 예 Phillips & Davis 현재 최선의 관행 [65페이지]
RFC 5646 언어 태그 2009년 9월 4.5. 언어 태그의 정규화 특정 언어 태그는 여러 프로세스에서 사용할 수 있으므로 언어 태그는 항상 정규 형식으로 생성하는 것이 좋습니다. 언어 태그가 2.1절 및 2.2절의 규칙에 따라 올바른 형식이고 IANA 레지스트리의 데이터(3.1절 참조)를 사용하여 다음 각 단계를 순서대로 적용해 정규화했다면 해당 언어 태그는 '정규 형식'입니다. 1. 확장 시퀀스는 singleton 하위 태그를 기준으로 대소문자를 구분하지 않는 ASCII 순서로 정렬합니다. * 예를 들어 하위 태그 시퀀스 '-a-babble'은 '-b-warble'보다 앞에 옵니다. 2. 중복 또는 기존 태그에 'Preferred- Value'가 있으면 해당 값으로 대체합니다. * 기존 및 중복 태그의 'Preferred-Value' field-body는 "확장 언어 범위" [RFC4647]이며 둘 이상의 하위 태그로 구성될 수 있습니다. * 레지스트리의 'Preferred-Value' 필드는 폐기된 태그에서 현대적 동등 값으로의 매핑을 제공합니다. 이 중 다수는 이 문서가 채택되기 전에 생성되었습니다(예: "no-nyn"을 "nn"으로 또는 "i-klingon"을 "tlh"로 매핑). 다른 일부는 이 문서에서 허용하거나 요구한 이후의 등록 또는 레지스트리 추가 결과입니다 (예를 들어 이 문서가 채택되었을 때 "zh-hakka"는 ISO 639-3 코드 'hak'을 위해 폐기되었습니다). 3. 하위 태그에 'Preferred-Value'가 있으면 해당 값으로 대체합니다. extlang의 경우 'Preferred- Value'에 기본 언어 하위 태그가 있으면 원래 기본 언어 하위 태그도 대체합니다. * extlang의 'Preferred-Value' field-body는 "확장 언어 범위"이며 일반적으로 기본 언어 하위 태그에 매핑됩니다. 예를 들어 하위 태그 시퀀스 "zh-hak"(중국어, 하카어)은 하위 태그 'hak' (하카어)으로 대체됩니다. * extlang이 아닌 대부분의 하위 태그는 국가 이름 또는 명칭이 변경된 Region 하위 태그이거나 ISO 639-1의 사무적 수정입니다. Phillips & Davis 현재 최선의 관행 [66페이지]
RFC 5646 언어 태그 2009년 9월 정규 형식에는 'extlang' 하위 태그가 없습니다. extlang 하위 태그를 유지하거나 복원하는 대체 'extlang 형식'이 있습니다. 이 형식은 일치 처리 또는 선택에서 'Prefix' 하위 태그의 존재가 유용하다고 간주되는 환경에서 유용할 수 있습니다(4.1.2절 참조). 언어 태그가 2.1절 및 2.2절의 규칙에 따라 올바른 형식이고 IANA 레지스트리의 데이터를 사용하여 다음 두 단계를 순서대로 적용해 처리했다면 해당 언어 태그는 'extlang 형식'입니다. 1. 먼저 위에서 설명한 대로 언어 태그를 정규 형식으로 변환합니다. 2. 언어 태그가 extlang 하위 태그이기도 한 기본 언어 하위 태그로 시작한다면 언어 태그 앞에 해당 extlang의 'Prefix'를 추가합니다. * 예를 들어 "hak-CN"(하카어, 중국)은 기본 언어 하위 태그 'hak'을 가지며, 이 하위 태그에는 다시 'zh'(중국어)를 'Prefix'로 갖는 'extlang' 레코드가 있습니다. extlang 형식은 "zh-hak-CN"(중국어, 하카어, 중국)입니다. * 2단계(접두사 추가)는 1단계(정규화)에서 제거된 하위 태그를 복원할 수 있다는 점에 유의하십시오. 예: 언어 태그 "en-a-aaa-b-ccc-bbb-x-xyz"는 정규 형식이지만, "en-b-ccc-bbb-a-aaa-X-xyz"는 올바른 형식이고 잠재적으로 유효합니다(이 문서가 게시될 당시 확장 'a' 및 'b'는 정의되지 않았습니다). 하지만 확장이 알파벳순으로 정렬되어 있지 않으므로 정규 형식은 아닙니다. 예: 태그 "en-BU"(버마에서 사용되는 영어)는 계속 유효하지만 'BU' 하위 태그에 'MM'(미얀마)으로의 정규 매핑이 있으므로 언어 태그 "en-BU"는 정규 형식이 아닙니다. 언어 태그를 정규화한다고 해서 하위 태그를 처리하거나 비교할 때 대문자나 소문자를 사용하는 것에 관한 의미가 생기는 것은 아닙니다 (2.1절에 설명된 것과 같습니다). 모든 비교는 대소문자를 구분하지 않는 방식으로 수행해야 합니다. 언어 태그를 정규화할 때 처리기는 레지스트리에서 사용되는 대소문자 표기(2.1.1절 참조)에 따라 하위 태그의 대소문자를 정규화할 수 있습니다(즉, 이 과정은 선택적입니다). Phillips & Davis 현재 최선의 관행 [67페이지]
RFC 5646 언어 태그 2009년 9월 하나의 태그 안에 둘 이상의 변형이 나타나면 처리기는 더 나은 일치 동작이나 더 일관된 표시를 얻기 위해 변형을 다시 정렬할 수 있습니다. 변형의 재정렬은 4.1절의 변형 순서 권장 사항을 따르는 것이 좋습니다. 레지스트리 레코드에 'Deprecated' 필드가 있지만 함께 제공되는 'Preferred-Value' 필드가 없다면 해당 태그 또는 하위 태그는 대체 항목 없이 폐기된 것입니다. 이러한 값은 언어 태그에 나타날 때 정규 값입니다. 그러나 이러한 값을 포함하는 태그를 사용자가 선택하거나 구현에서 생성하지 않는 것이 좋습니다. 확장은 확장 내의 여러 하위 태그 사이에 존재하는 모든 관계를 정의해야 하며, 따라서 확장 하위 태그에 대한 대체 정규화 방식을 정의할 수도 있습니다. 확장은 확장 하위 태그의 순서를 해석하는 방식을 정의할 수 있습니다. 예를 들어 어떤 확장은 하위 태그가 ASCII 순서로 배치될 때 정규 순서라고 정의할 수 있습니다. 즉, "en-a-ccc-bbb-aaa"가 아니라 "en-a- aaa-bbb-ccc"입니다. 다른 확장은 하위 태그 순서가 그 의미에 영향을 준다고 정의할 수 있습니다(따라서 "en-b-ccc-bbb-aaa"와 "en-b- aaa-bbb-ccc"가 서로 다른 값을 가집니다). 그러나 확장 규격은 3.7절에 설명된 일반적인 프로세스를 허용하도록 설계하는 것이 좋습니다. 4.6. 사적 사용 하위 태그에 대한 고려 사항 사적 사용 하위 태그는 다른 모든 하위 태그와 마찬가지로 ABNF의 형식 및 내용 제한을 준수해야 합니다. 사적 사용 하위 태그는 이를 사용하는 언어 태그를 사용하거나 교환하려는 당사자 사이의 사적 합의 밖에서는 의미가 없습니다. 동일한 하위 태그를 별도의 사적 합의에 따라 다른 의미로 사용할 수도 있습니다. 대안이 존재하는 경우에는 사용하지 않는 것이 좋으며 일반 용도의 콘텐츠나 프로토콜에도 사용하지 않는 것이 좋습니다. 사전 합의가 없다면 사적 사용 하위 태그는 정보 교환에 아무런 쓸모가 없습니다. 사적 사용 태그와 그러한 언어 태그 안에서 사용되는 하위 태그의 값 및 의미는 이 문서에서 정의하지 않습니다. 'x' singleton으로 시작하는 사적 사용 시퀀스는 사적 사용 합의 외부의 사용자나 구현에는 완전히 불투명합니다. 따라서 singleton 하위 태그 'x'로 시작하는 사적 사용 하위 태그 시퀀스 외에도 언어 하위 태그 레지스트리는 기반 표준에서 할당한 사적 사용 코드에서 파생된 사적 사용 언어, 문자 체계 및 지역 하위 태그를 제공합니다. 이러한 하위 태그는 언어 태그를 구성하는 데 유효하며 'x' singleton 사적 사용 하위 태그 시퀀스보다 사용하는 것이 권장됩니다. Phillips & Davis 현재 최선의 관행 [68페이지]
RFC 5646 언어 태그 2009년 9월 이는 언어 태그의 고유한 구조와의 연결을 통해 더 많은 정보를 전달하기 때문입니다. 예를 들어 지역 하위 태그 'AA', 'ZZ', 그리고 'QM'-'QZ' 및 'XA'-'XZ' 범위의 하위 태그(ISO 3166-1 사적 사용 코드에서 파생)는 언어 태그를 구성하는 데 사용할 수 있습니다. "zh-Hans-XQ"와 같은 태그는 언어 자료에 관한 많은 공개적이고 상호 교환 가능한 정보를 전달합니다(간체자로 작성된 중국어이며 어떤 지리적 지역 'XQ'에 적합함). 정확한 지리적 지역은 사적 합의 밖에서는 알 수 없지만, 이 태그는 "x-somelang"과 같은 불투명한 태그나 심지어 "zh-Hans-x-xq"('xq' 하위 태그의 의미가 완전히 불투명함)보다 훨씬 많은 정보를 전달합니다. 그러나 경우에 따라 사적 사용 하위 태그로 표시된 콘텐츠는 불투명하고 사적으로 정의된 하위 태그를 사용하는 태그와 비교하여 다른 시스템과 다르고 잠재적으로 부적절한 방식으로 상호작용할 수 있으므로 가장 좋은 접근 방식의 선택은 해당 영역에 따라 달라질 수 있습니다. 5. IANA 고려 사항 이 절에서는 이 문서에서 정의하고 [RFC5226]의 요구 사항에 따라 IANA가 하위 태그 및 확장 레지스트리를 유지 관리하는 데 필요한 프로세스와 요구 사항을 다룹니다. 이 문서에서 정의하는 두 레지스트리의 IANA 유지 관리자에게 미치는 영향은 새 항목 또는 업데이트 빈도가 소폭 증가하는 것입니다. 또한 IANA는 레지스트리 변경 및 업데이트를 알리기 위한 새로운 메일링 리스트(아래 5.1절에서 설명)를 만들어야 합니다. 5.1. 언어 하위 태그 레지스트리 IANA는 동반 문서 [RFC5645]에서 제공한 지침과 내용을 사용하여 레지스트리를 업데이트했습니다. 업데이트된 레코드 집합을 선택하는 기준과 절차는 해당 문서에 설명되어 있습니다. 업데이트된 레코드 집합을 생성하는 작업은 외부에서 수행되므로 IANA에 미치는 영향은 없습니다. 향후 언어 하위 태그 레지스트리에 관한 작업에는 다음 활동이 포함됩니다. o 전체 레코드를 삽입하거나 교체합니다. 이러한 레코드는 3.3절에 설명된 대로 언어 하위 태그 검토자가 IANA를 위해 미리 형식을 지정합니다. o 등록 양식을 보관하고 공개적으로 이용할 수 있게 합니다. Phillips & Davis 현재 최선의 관행 [69페이지]
RFC 5646 언어 태그 2009년 9월 o 레지스트리의 각 업데이트 버전을 "ietf-languages-announcements@iana.org" 메일링 리스트에 알립니다. IANA에 보내는 각 등록 양식에는 레지스트리에 통합할 하나의 레코드가 포함됩니다. 양식은 언어 하위 태그 검토자가 <iana@iana.org>로 보냅니다. 제목 줄에는 포함된 양식이 새 레코드 삽입을 나타내는지 (제목 줄의 "INSERT"라는 단어로 표시) 또는 기존 레코드 교체를 나타내는지(제목 줄의 "MODIFY"라는 단어로 표시)가 표시됩니다. 레지스트리에서 레코드를 삭제할 수는 없습니다. IANA는 양식에서 레코드를 추출하여 삽입 또는 수정된 레코드를 Language Subtag Registry의 적절한 섹션에 배치하고 'Type' 필드를 기준으로 레코드를 그룹화합니다. 삽입된 레코드는 적절한 섹션 안의 어느 위치에나 배치할 수 있으며, 레지스트리의 레코드는 항상 'Type'별로 그룹화된다는 점 외에는 특정 순서로 배치된다는 보장이 없습니다. 수정된 레코드는 대체 대상 레코드를 덮어씁니다. 레지스트리에서 항목이 생성되거나 수정될 때마다 레지스트리 시작 부분의 'File- Date' 레코드는 가장 최근 수정 날짜를 반영하도록 업데이트됩니다. 날짜 형식은 [RFC3339]의 "full- date" 형식이어야 합니다. 날짜는 해당 버전의 레지스트리를 IANA가 처음 게시한 날짜여야 합니다. 하루에 게시되는 레지스트리 버전은 최대 하나여야 합니다. 레코드를 삽입하거나 수정하도록 IANA에 보내는 각 요청에도 요청 안의 레코드 승인 날짜를 나타내는 'File- Date' 레코드가 포함됩니다. 업데이트된 레지스트리 파일은 UTF-8 문자 인코딩을 사용해야 하며, IANA는 레지스트리 파일의 인코딩이 올바른지 확인해야 합니다. 비ASCII 문자는 등록 양식을 이메일 메시지에 첨부하거나 메일 메시지 본문에서 여러 인코딩을 사용하여 IANA에 보낼 수 있습니다 (UTF-8 권장). IANA는 불분명하거나 손상된 문자를 업데이트된 레지스트리를 게시하기 전에 언어 하위 태그 검토자와 확인합니다. IANA는 또한 각 등록 양식을 보관하고 http://www.iana.org에서 공개적으로 이용할 수 있게 합니다. 여러 등록이 레지스트리의 동일한 레코드와 관련될 수 있다는 점에 유의하십시오. 언어 하위 태그 레지스트리에 의존하는 개발자는 구현을 업데이트할 수 있도록 레지스트리 변경 사항을 알림받기를 원하는 경우가 있습니다. 언어 하위 태그 레지스트리가 변경될 때마다 IANA는 <ietf-languages-announcements@iana.org>(IANA만 게시할 수 있는 자체 구독 목록)로 알림 메시지를 보냅니다. Phillips & Davis 현재 최선의 관행 [70페이지]
RFC 5646 언어 태그 2009년 9월 5.2. 확장 레지스트리 Language Tag Extensions Registry에는 최대 35개의 레코드만 포함될 수 있으므로 이 레지스트리의 변경은 매우 드물 것으로 예상됩니다. IANA의 Language Tag Extensions Registry에 대한 향후 작업은 두 가지 경우로 제한됩니다. 첫째, IESG는 때때로 이 레지스트리에 새 레코드를 삽입하도록 요청할 수 있습니다. 이러한 요청에는 3.7절에 설명된 정확한 형식의 삽입할 레코드를 포함해야 합니다. 또한 특정 확장의 유지 관리 기관에서 레코드의 연락처 정보 또는 URL을 업데이트해 달라는 요청이 간혹 있을 수 있습니다. 이러한 요청에는 업데이트된 전체 레코드를 포함해야 합니다. IANA는 제공된 정보를 검증할 책임이 없으며 올바른 형식인지 여부만 확인합니다. IANA는 요청이 레지스트리에 있는 레코드에 명시된 유지 관리 기관에서 온 것인지 확인하기 위해 합리적인 조치를 취하는 것이 좋습니다. 6. 보안 고려 사항 콘텐츠 협상에 사용되는 언어 태그는 인터넷에서 교환되는 다른 모든 정보와 마찬가지로 발신자의 국적을 추론하는 데 사용될 수 있고, 따라서 감시 대상이 될 가능성이 있는 사람을 식별하는 데 사용될 수 있으므로 우려의 원인이 될 수 있습니다. 이는 전송되는 모든 것이 수신자에게, 그리고 잠재적으로 제3자에게도 보인다는 일반적인 문제의 특수한 사례입니다. 이러한 우려가 일부 경우에 존재할 수 있다는 점을 인식하는 것이 유용합니다. 위협의 정확한 규모와 가능한 대응책의 평가는 각 애플리케이션 프로토콜에 맡깁니다(보안 위협과 방어에 관한 현재 최선의 관행 지침은 BCP 72 [RFC3552] 참조). 특정 정보 항목과 연결된 언어 태그는 해당 콘텐츠에 동형 문자가 포함될 가능성이 있는지 판단하는 데 아무런 영향도 미치지 않습니다. 텍스트가 특정 언어로 태그되어 있거나 특정 문자 체계 하위 태그를 사용한다고 해서 해당 언어 태그와 연결되거나 지정된 문자 체계 이외의 문자 체계에 속한 문자가 포함되어 있지 않다고 전혀 보장할 수 없습니다. 변형, 사적 사용 및 확장 하위 태그의 수에는 제한이 없고 따라서 태그의 가능한 길이에도 제한이 없으므로 구현은 버퍼 오버플로 공격에 대비해야 합니다. 버퍼 오버플로 방어의 결과로 발생할 수 있는 언어 태그 자르기에 관한 자세한 내용은 4.4절을 참조하십시오. Phillips & Davis 현재 최선의 관행 [71페이지]
RFC 5646 언어 태그 2009년 9월 서비스 거부 공격을 방지하기 위해 애플리케이션은 Language Subtag Registry 또는 Language Tag Extensions Registry가 항상 접근 가능하다는 것에 의존하지 않는 것이 좋습니다. 또한 확장에 대한 유효한 하위 태그의 규격(3.7절 참조)은 인터넷을 통해 이용할 수 있어야 하지만 구현은 해당 출처가 항상 접근 가능하다는 것에 기계적으로 의존하지 않는 것이 좋습니다. 이 문서에 규정된 레지스트리는 레지스트리 전체 내용에 대한 빈번한 또는 실시간 접근이나 검색에 적합하지 않습니다. 대부분의 애플리케이션에는 레지스트리 데이터가 전혀 필요하지 않습니다. 다른 애플리케이션에서는 레지스트리 내용이 가끔만 변경되므로 특정 레지스트리 날짜를 기준으로 언어 태그를 검증하거나 정규화할 수 있으면 충분합니다. 변경 사항은 <ietf-languages-announcements@iana.org>에 공지됩니다. 이 메일링 리스트는 관심 있는 조직과 개인을 위한 것이며 자동 소프트웨어 업데이트를 실행하기 위한 대량 구독용이 아닙니다. 레지스트리의 크기 때문에 자동 소프트웨어 업데이트에 적합하지 않습니다. Language Subtag Registry를 자동 업데이트 방식에 통합하려는 구현자는 적절히 인코딩된 차이점만 자신의 인프라를 통해 배포하고, IANA에서 직접 배포하지 않는 것이 강하게 권장됩니다. 변경 사항 또는 변경 사항이 없다는 사실은 레지스트리 시작 부분의 'File-Date' 레코드를 확인하거나 전체 레지스트리를 다운로드할 필요 없이 다운로드에 사용되는 프로토콜의 기능을 사용해서도 쉽게 감지할 수 있습니다. 이 문서가 게시될 당시 IANA는 Language Tag Registry를 HTTP 1.1을 통해 제공하고 있습니다. HTTP 1.1을 사용하여 Language Subtag Registry의 로컬 사본을 업데이트하는 올바른 방법은 조건부 GET [RFC2616]을 사용하는 것입니다. 7. 문자 집합 고려 사항 이 문서의 구문은 언어 태그가 대부분의 문자 집합에 존재하는 A-Z, a-z, 0-9 및 HYPHEN-MINUS 문자만 사용하도록 요구하므로 언어 태그 구성에는 문자 집합과 관련된 문제가 없어야 합니다. 언어 태그에 기반한 텍스트 렌더링은 여기에서 다루지 않습니다. 역사적으로 일부 프로세스는 특정 문자 문자열을 어떻게 렌더링해야 하는지 추론하기 위해 문자 집합/인코딩 정보(또는 기타 외부 정보)의 사용에 의존해 왔습니다. 특히 이는 일본어, 중국어 및 한국어에서 사용되는 한자의 언어 및 문화별 변형에 적용됩니다. 예를 들어 EUC-JP와 같은 일본어 문자 인코딩을 사용하면 텍스트 자체가 일본어임을 암시합니다. 언어 태그가 텍스트 범위에 적용되면 렌더링 엔진은 해당 정보를 사용하여 글꼴을 더 적절하게 선택하거나 다른 렌더링 Phillips & Davis 현재 최선의 관행 [72페이지]
RFC 5646 언어 태그 2009년 9월 선택을 할 수 있습니다. 특히 서로 다른 표기 전통을 가진 언어가 동일한 문자를 사용하는 경우에 그렇습니다. 8. RFC 4646에서의 변경 사항 이 RFC 4646 개정의 주요 목표는 ISO 639의 두 새로운 부분 (ISO 639-3 및 ISO 639-5)과 이에 수반되는 언어 코드 집합을 IANA Language Subtag Registry에 통합하는 것이었습니다. 이를 통해 이전에 지원하던 것보다 훨씬 더 많은 언어와 언어 집합을 식별할 수 있습니다. 이러한 목표를 달성하기 위한 이 문서의 구체적인 변경 사항은 다음과 같습니다. o ISO 639-3 및 ISO 639-5 코드를 기본 및 확장 언어 하위 태그로 사용하도록 통합하는 방식을 정의했습니다. 또한 추가 'extlang' 하위 태그 사용을 영구적으로 예약하고 허용하지 않습니다. 이를 달성하는 데 필요한 변경 사항은 다음과 같습니다. * ABNF 주석을 수정했습니다. * 여러 등록 및 안정성 요구 사항 절을 업데이트하여 ISO 639-1 및 ISO 639-2 외에도 ISO 639-3 및 ISO 639-5를 참조하도록 했습니다. * 더 이상 사용되지 않는 곳에서 확장 언어 하위 태그에 대한 참조를 제거하도록 텍스트를 편집했습니다. * 확장 언어 하위 태그에 관한 절에서 변경 사항을 설명했습니다. o 기존 태그와 관련된 ABNF를 변경했습니다. 이제 비정규 태그가 나열됩니다. 올바른 형식의 기존 태그는 이제 'langtag' 생성 규칙으로 설명되며 그 결과 'grandfathered' 생성 규칙이 제거되었습니다. 또한 두 유형의 기존 태그에 관한 설명을 2.2.8절에 추가했습니다. o 4.1절에 "집합"에 관한 단락을 추가했습니다. o 3.1절의 'Tag' 필드 대소문자 표기 규칙을 변경했습니다. o 3.1절을 여러 하위 절로 분할했습니다. o 등록 절차를 통해 'Suppress-Script' 필드를 추가, 수정 또는 제거할 수 있도록 3.5절을 수정했습니다. 이는 RFC 4646의 오류 정정 사항이었습니다. o 지역 코드 'CS'(이전 세르비아 몬테네그로)를 사용하던 예를 'RS'(세르비아)를 사용하도록 수정했습니다. Phillips & Davis 현재 최선의 관행 [73페이지]
RFC 5646 언어 태그 2009년 9월 o 역순 중복을 포함한 중복을 방지하도록 레코드 'Description' 필드를 생성하고 유지 관리하는 규칙을 수정했습니다. o 이 절에서 RFC 4646이 만들어진 이유에 관한 긴 설명을 제거했으며, 이로 인해 XML Schema에 대한 참조도 제거되었습니다. o 언어 태그가 대소문자를 구분하지 않는다는 사실을 더 강조하도록 2.1절의 텍스트를 수정했습니다. o "fr-Latn-CA"는 'fr'에 대한 'Latn'의 'Suppress-Script'를 준수하지 않으므로 2.1절의 예 "fr-Latn-CA"를 "sr-Latn-RS" 및 "az-Arab-IR"로 교체했습니다. o 올바른 형식에 대한 요구 사항을 변경하여 singleton 반복 확인을 선택 사항으로 만들었습니다(유효성 확인에는 필요함). 2.2.9절을 참조하십시오. o 기존 태그 확인을 언급하는 2.2.9절의 텍스트를 변경하여 이제 목록이 ABNF에 포함되어 있음을 명시했습니다. o 3.2절의 텍스트를 수정하고 추가했습니다. 직무 설명을 맨 앞에 배치했습니다. 언어 하위 태그 검토자가 목록 관리 등을 포함한 중요하지 않은 여러 업무를 위임할 수 있음을 명확히 하는 참고를 추가했습니다. 마지막으로 임명 절차를 명확히 하고 검토자의 결정 및 업무 수행에 이의를 제기할 수 있음을 명확히 하기 위한 텍스트를 추가했습니다. o ietf-languages@iana.org 목록을 IESG가 지정한 주체가 운영한다는 점을 명확히 하는 텍스트를 3.5절에 추가했습니다. o 'language' 레코드의 첫 번째 Description이 ISO 639-3에서 해당 언어의 Reference Name과 일치한다는 점을 명확히 하는 텍스트를 3.1.5절에 추가했습니다. o 특정 태그와 관련된 적합성 클래스를 정의하도록 2.2.9절을 수정했습니다(이전에는 'well-formed' 및 'valid'가 구현을 가리켰습니다). 이전 정의를 사용하여 올바른 형식을 허용하기 위해 RFC 4646에 제공된 ABNF에서 'extlang' 제거에 관한 참고를 추가했습니다. RFC 3066의 올바른 형식에 대한 참조도 추가했습니다. o 이 문서의 향후 버전에서 레지스트리 형식에 새로운 필드 유형을 추가할 수 있음을 설명하고 구현이 인식하지 못하는 필드를 무시할 것을 권장하는 텍스트를 3.1.2절 끝에 추가했습니다. Phillips & Davis 현재 최선의 관행 [74페이지]
RFC 5646 언어 태그 2009년 9월 o 레코드에 'Suppress-Script' 필드가 없다는 것이 무엇을 의미하는지 설명하는 텍스트를 3.1.9절에 추가했습니다. o 철자 오류 및 인쇄상 오류의 수정을 허용하는 텍스트를 3.1.5절에 추가했습니다. o 'Prefix' 필드 충돌(예: 순환 접두사 참조)을 허용하지 않는 텍스트를 3.1.8절에 추가했습니다. o 2주 기간이 지난 뒤 하위 태그 검토자가 자신의 결정(또는 연장)을 공지하도록 요구하는 내용으로 3.5절의 텍스트를 수정했습니다. 또한 모든 결정 또는 결정하지 못한 경우에도 이의를 제기할 수 있음을 명확히 했습니다. o 지금까지 일화적으로 다루었던 태그 선택의 기본 원칙을 포함하고, 비문자 애플리케이션에서 문자 체계 하위 태그를 사용하지 않음을 명확히 하도록 4.1절의 텍스트를 수정했습니다. o 하나의 태그에서 동일한 변형을 여러 번 사용하는 것을 금지했습니다 (예: "de- 1901-1901"). 이전에는 권장 사항("SHOULD")에 불과했습니다. o 4.4.1절의 예시에서 부적절한 [RFC2119] 표현을 제거했습니다. o 4.5절에서 "zh-guoyu" 폐기 예를 "zh- hakka"->"hak"으로 교체하고 이 변경이 이 문서로 인해 이루어졌음을 명시했습니다. o 4.1절의 "mul"/"und"를 다루는 부분을 교체하여 하위 태그 'zxx', 'mis'와 태그 "i-default"를 포함하도록 했습니다. RFC 2277에 대한 규범적 참조를 추가했습니다. o 등록 요청의 모든 수정 사항을 IANA에 제출하기 전에 <ietf-languages@iana.org> 목록에 보내야 한다는 점을 명확히 하는 텍스트를 3.5절에 추가했습니다. o record-jar 형식의 ABNF를 LWSP 생성 규칙 대신 [RFC5234]의 obs- FWS와 유사한 접기 공백 생성 규칙을 사용하도록 변경했습니다. 이는 사실상 필드 안에 의도하지 않은 빈 줄이 생기는 것을 방지합니다. o 언어 하위 태그 검토자가 완전한 등록 양식을 IANA에 보내고, IANA가 양식에서 레코드를 추출하며, 양식도 레지스트리와 별도로 보관해야 한다는 점을 명확히 하도록 3.3절, 3.5절 및 5.1절의 텍스트를 명확히 하고 수정했습니다. Phillips & Davis 현재 최선의 관행 [75페이지]
RFC 5646 언어 태그 2009년 9월 o 레지스트리가 업데이트될 때마다 IANA가 ietf-languages-announcements 목록에 공지를 보내도록 요구하는 텍스트를 5절에 추가했습니다. o 레지스트리가 문자 인코딩으로 UTF-8을 사용하도록 수정했습니다. 이에 따라 등록 절차에서 IANA와 언어 하위 태그 검토자에 대한 추가 지침도 포함됩니다. o 'UK' 이외의 "예외적으로 예약된" ISO 3166-1 코드가 레지스트리에 포함되도록 2.2.4절의 규칙을 수정했습니다. 특히 이를 통해 코드 'EU'(European Union)를 언어 태그 구성에 사용하거나 (더 일반적으로) 지역 코드용 레지스트리를 사용하는 애플리케이션에서 이 하위 태그를 참조할 수 있습니다. o 불필요한 규범적 [RFC2119] 표현을 제거하도록 IANA 고려 사항 절 (5절)을 수정했습니다. 9. 참고 문헌 9.1. 규범적 참고 문헌 [ISO15924] International Organization for Standardization, "ISO 15924:2004. 정보 및 문서화 -- 문자 체계 이름 표현을 위한 코드", 2004년 1월. [ISO3166-1] International Organization for Standardization, "ISO 3166-1:2006. 국가 및 그 하위 구역 이름 표현을 위한 코드 -- 제1부: 국가 코드", 2006년 11월. [ISO639-1] International Organization for Standardization, "ISO 639-1:2002. 언어 이름 표현을 위한 코드 -- 제1부: Alpha-2 코드", 2002년 7월. [ISO639-2] International Organization for Standardization, "ISO 639-2:1998. 언어 이름 표현을 위한 코드 -- 제2부: Alpha-3 코드", 1998년 10월. [ISO639-3] International Organization for Standardization, "ISO 639-3:2007. 언어 이름 표현을 위한 코드 - 제3부: 언어를 포괄적으로 다루기 위한 Alpha-3 코드", 2007년 2월. Phillips & Davis 현재 최선의 관행 [76페이지]
RFC 5646 언어 태그 2009년 9월 [ISO639-5] International Organization for Standardization, "ISO 639-5:2008. 언어 이름 표현을 위한 코드 -- 제5부: 언어 계통 및 그룹을 위한 Alpha-3 코드", 2008년 5월. [ISO646] International Organization for Standardization, "ISO/IEC 646:1991, 정보 기술 -- 정보 교환을 위한 ISO 7비트 부호화 문자 집합.", 1991년. [RFC2026] Bradner, S., "인터넷 표준 절차 -- 개정 3", BCP 9, RFC 2026, 1996년 10월. [RFC2119] Bradner, S., "요구 수준을 나타내기 위해 RFC에서 사용하는 핵심 단어", BCP 14, RFC 2119, 1997년 3월. [RFC2277] Alvestrand, H., "문자 집합과 언어에 관한 IETF 정책", BCP 18, RFC 2277, 1998년 1월. [RFC3339] Klyne, G., Ed. and C. Newman, "인터넷상의 날짜와 시간: 타임스탬프", RFC 3339, 2002년 7월. [RFC4647] Phillips, A. and M. Davis, "언어 태그 일치", BCP 47, RFC 4647, 2006년 9월. [RFC5226] Narten, T. and H. Alvestrand, "RFC에서 IANA 고려 사항 절을 작성하기 위한 지침", BCP 26, RFC 5226, 2008년 5월. [RFC5234] Crocker, D. and P. Overell, "구문 규격을 위한 확장 BNF: ABNF", STD 68, RFC 5234, 2008년 1월. [SpecialCasing] The Unicode Consoritum, "유니코드 문자 데이터베이스, 특수 대소문자 속성", 2008년 3월, <http:// unicode.org/Public/UNIDATA/SpecialCasing.txt>. [UAX14] Freitag, A., "유니코드 표준 부록 #14: 줄 바꿈 속성", 2006년 8월, <http://www.unicode.org/reports/tr14/>. [UN_M.49] Statistics Division, United Nations, "통계용 표준 국가 또는 지역 코드", 개정 4 (United Nations publication, Sales No. 98.XVII.9, 1999년 6월). Phillips & Davis 현재 최선의 관행 [77페이지]
RFC 5646 언어 태그 2009년 9월 [Unicode] Unicode Consortium, "The Unicode Consortium. 유니코드 표준, 버전 5.0, (Boston, MA, Addison- Wesley, 2003. ISBN 0-321-49081-0)", 2007년 1월. 9.2. 정보 제공용 참고 문헌 [CLDR] "공통 로케일 데이터 저장소 프로젝트", <http://cldr.unicode.org>. [RFC1766] Alvestrand, H., "언어 식별용 태그", RFC 1766, 1995년 3월. [RFC2028] Hovey, R. and S. Bradner, "IETF 표준 절차에 참여하는 조직", BCP 11, RFC 2028, 1996년 10월. [RFC2046] Freed, N. and N. Borenstein, "다목적 인터넷 메일 확장(MIME) 제2부: 미디어 유형", RFC 2046, 1996년 11월. [RFC2047] Moore, K., "MIME(다목적 인터넷 메일 확장) 제3부: 비ASCII 텍스트를 위한 메시지 헤더 확장", RFC 2047, 1996년 11월. [RFC2231] Freed, N. and K. Moore, "MIME 매개변수 값 및 인코딩된 단어 확장: 문자 집합, 언어 및 연속", RFC 2231, 1997년 11월. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "하이퍼텍스트 전송 프로토콜 -- HTTP/1.1", RFC 2616, 1999년 6월. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, ISO 10646의 인코딩", RFC 2781, 2000년 2월. [RFC3066] Alvestrand, H., "언어 식별용 태그", RFC 3066, 2001년 1월. [RFC3282] Alvestrand, H., "콘텐츠 언어 헤더", RFC 3282, 2002년 5월. [RFC3552] Rescorla, E. and B. Korver, "보안 고려 사항에 관한 RFC 텍스트 작성 지침", BCP 72, RFC 3552, 2003년 7월. Phillips & Davis 현재 최선의 관행 [78페이지]
RFC 5646 언어 태그 2009년 9월 [RFC3629] Yergeau, F., "UTF-8, ISO 10646의 변환 형식", STD 63, RFC 3629, 2003년 11월. [RFC4645] Ewell, D., "초기 언어 하위 태그 레지스트리", RFC 4645, 2006년 9월. [RFC4646] Phillips, A. and M. Davis, "언어 식별용 태그", BCP 47, RFC 4646, 2006년 9월. [RFC5645] Ewell, D., Ed., "언어 하위 태그 레지스트리 업데이트", 2009년 9월. [UTS35] Davis, M., "유니코드 기술 표준 #35: 로케일 데이터 마크업 언어(LDML)", 2007년 12월, <http://www.unicode.org/reports/tr35/>. [iso639.prin] ISO 639 Joint Advisory Committee, "ISO 639 공동 자문 위원회: ISO 639 유지 관리를 위한 작업 원칙", 2000년 3월, <http://www.loc.gov/ standards/iso639-2/iso639jac_n3r.html>. [record-jar] Raymond, E., "유닉스 프로그래밍의 기술", 2003년, <urn:isbn:0-13-142901-9>. Phillips & Davis 현재 최선의 관행 [79페이지]
RFC 5646 언어 태그 2009년 9월 부록 A. 언어 태그의 예(정보 제공용) 단순 언어 하위 태그: de (독일어) fr (프랑스어) ja (일본어) i-enochian (기존 태그의 예) 언어 하위 태그와 문자 체계 하위 태그: zh-Hant (번체자로 작성된 중국어) zh-Hans (간체자로 작성된 중국어) sr-Cyrl (키릴 문자로 작성된 세르비아어) sr-Latn (라틴 문자로 작성된 세르비아어) 확장 언어 하위 태그와 이에 대응하는 기본 언어 하위 태그: zh-cmn-Hans-CN (중국어, 관화, 간체자, 중국에서 사용됨) cmn-Hans-CN (관화, 간체자, 중국에서 사용됨) zh-yue-HK (중국어, 광둥어, 홍콩 특별행정구에서 사용됨) yue-HK (광둥어, 홍콩 특별행정구에서 사용됨) 언어-문자 체계-지역: zh-Hans-CN (중국 본토에서 사용되는 간체자로 작성된 중국어) sr-Latn-RS (세르비아에서 사용되는 라틴 문자로 작성된 세르비아어) Phillips & Davis 현재 최선의 관행 [80페이지]
RFC 5646 언어 태그 2009년 9월 언어-변형: sl-rozaj (슬로베니아어의 Resian 방언) sl-rozaj-biske (슬로베니아어 Resian 방언의 San Giorgio 방언) sl-nedis (슬로베니아어의 Nadiza 방언) 언어-지역-변형: de-CH-1901 (1901 변형[철자법]을 사용하는 스위스의 독일어) sl-IT-nedis (이탈리아에서 사용되는 슬로베니아어, Nadiza 방언) 언어-문자 체계-지역-변형: hy-Latn-IT-arevela (이탈리아에서 사용되는 라틴 문자로 작성된 동부 아르메니아어) 언어-지역: de-DE (독일의 독일어) en-US (미국에서 사용되는 영어) es-419 (UN 지역 코드를 사용하는 라틴 아메리카 및 카리브 지역에 적합한 스페인어) 사적 사용 하위 태그: de-CH-x-phonebk az-Arab-x-AZE-derbend 사적 사용 레지스트리 값: x-whatever (singleton 'x'를 사용하는 사적 사용) qaa-Qaaa-QM-x-southern (모두 사적 태그) de-Qaaa (독일어, 사적 문자 체계) sr-Latn-QM (세르비아어, 라틴 문자, 사적 지역) sr-Qaaa-RS (세르비아어, 사적 문자 체계, 세르비아용) Phillips & Davis 현재 최선의 관행 [81페이지]
RFC 5646 언어 태그 2009년 9월 확장을 사용하는 태그(예시일 뿐임 -- 확장은 이 문서의 개정 또는 업데이트나 RFC에서 정의해야 함): en-US-u-islamcal zh-CN-a-myext-x-private en-a-myext-b-another 유효하지 않은 태그의 예: de-419-DE (두 개의 지역 태그) a-DE (기본 위치에서 단일 문자 하위 태그 사용. "i-"로 시작하는 유효한 기존 태그가 몇 개 있다는 점에 유의) ar-a-aaa-b-bbb-a-ccc (동일한 단일 문자 접두사를 가진 두 확장) 부록 B. 등록 양식의 예 언어 하위 태그 등록 양식 1. 요청자 이름: Han Steenwijk 2. 요청자의 이메일 주소: han.steenwijk @ unipd.it 3. 요청된 레코드: Type: variant Subtag: biske Description: Resian의 San Giorgio 방언 Description: Resian의 Bila 방언 Prefix: sl-rozaj Comments: San Giorgio/Bila 방언은 Resian의 네 주요 지역 방언 중 하나입니다 4. 하위 태그의 의도된 의미: San Giorgio/Bila에서 사용되는 Resian의 지역 변종 5. 언어에 대해 출판된 설명(책 또는 논문)의 참고 문헌: -- Jan I.N. Baudouin de Courtenay - Opyt fonetiki rez'janskich govorov, Varsava - Peterburg: Vende - Kozancikov, 1875. Phillips & Davis 현재 최선의 관행 [82페이지]
RFC 5646 언어 태그 2009년 9월 언어 하위 태그 등록 양식 1. 요청자 이름: Jaska Zedlik 2. 요청자의 이메일 주소: jz53 @ zedlik.com 3. 요청된 레코드: Type: variant Subtag: tarask Description: Taraskievica 철자법으로 작성된 벨라루스어 Prefix: be Comments: 이 하위 태그는 Juras Buslakou, Vincuk Viacorka, Zmicier Sanko 및 Zmicier Sauka의 "Bielaruski klasycny pravapis" (Vilnia-Miensk 2005)에 출판된 Branislau Taraskievic의 벨라루스어 철자법을 나타냅니다. 4. 하위 태그의 의도된 의미: 이 하위 태그는 Juras Buslakou, Vincuk Viacorka, Zmicier Sanko 및 Zmicier Sauka의 "Bielaruski klasycny pravapis" (Vilnia-Miensk 2005)에 출판된 벨라루스어 철자법을 나타내기 위한 것입니다. 5. 언어에 대해 출판된 설명(책 또는 논문)의 참고 문헌: Taraskievic, Branislau. Bielaruskaja gramatyka dla skol. Vilnia: Vyd. "Bielaruskaha kamitetu", 1929, 제5판. Buslakou, Juras; Viacorka, Vincuk; Sanko, Zmicier; Sauka, Zmicier. Bielaruski klasycny pravapis. Vilnia-Miensk, 2005. 6. 기타 관련 정보: Taraskievica 철자법으로 작성된 벨라루스어는 특히 벨라루스어 사용 인터넷 영역에서 널리 사용되게 되었으며, 그 밖에도 일부 책과 신문이 이 벨라루스어 철자법을 사용하여 인쇄되고 있습니다. 부록 C. 감사의 말 기여자 목록은 필연적으로 불완전할 수밖에 없습니다. 다음 목록은 이 문서를 현재의 모습으로 만드는 데 기여한 사람들 가운데 일부만 선정한 것으로 보아 주십시오. 이 문서의 전신인 RFC 4646, RFC 4647, RFC 3066 및 RFC 1766의 기여자들은 직간접적으로 이 문서에 막대한 기여를 했으며, 일반적으로 언어 태그의 성공에 크게 기여했습니다. Phillips & Davis 현재 최선의 관행 [83페이지]
RFC 5646 언어 태그 2009년 9월 다음 사람들이 이 문서에 기여했습니다. Stephane Bortzmeyer, Karen Broome, Peter Constable, John Cowan, Martin Duerst, Frank Ellerman, Doug Ewell, Deborah Garside, Marion Gunn, Alfred Hoenes, Kent Karlsson, Chris Newman, Randy Presuhn, Stephen Silver, Shawn Steele 및 그 밖의 많은 분들입니다. RFC 1766 및 3066을 처음 만든 Harald Tveit Alvestrand에게 특별한 감사를 드립니다. 이분이 없었다면 이 문서는 존재할 수 없었을 것입니다. 거의 전체 RFC 1766/RFC 3066 기간 동안 Language Tag Reviewer로 활동했으며 RFC 4646 채택 이후 Language Subtag Reviewer로 활동한 Michael Everson에게 특별한 감사를 드립니다. 최초의 완전한 하위 태그 레지스트리를 제작하고 새로운 등록을 지원하고 유지 관리하는 작업을 수행했으며 RFC 4645 및 [RFC5645] 모두를 세심하게 편집한 Doug Ewell에게도 특별한 감사를 드립니다. 저자 주소 Addison Phillips (편집자) Lab126 이메일: addison@inter-locale.com URI: http://www.inter-locale.com Mark Davis (편집자) Google 이메일: markdavis@google.com Phillips & Davis 현재 최선의 관행 [84페이지]