네트워크 작업 그룹 A. Phillips, Ed. 의견 요청서: 5646 Lab126 BCP: 47 M. Davis, Ed. 폐기: 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" ; irregular 태그는 'langtag' / "i-ami" ; 생산식과 일치하지 않으며 / "i-bnn" ; 그렇지 않으면 'well-formed'로 / "i-default" ; 간주되지 않을 것이다 / "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 문자 데이터베이스 파일 "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, Codes for the representation of names of languages -- Part 1: Alpha-2 code" [ISO639-1] 표준에서 발견되는 할당에 따라, 또는 이후 ISO 639-1 등록 기관(RA)이나 관리 표준화 기구가 수행한 할당을 사용하여 IANA 등록소에 정의되었다. 2. IANA 등록소의 세 문자 기본 언어 하위 태그는 다음 추가 ISO 639 부문 중 하나에서 발견되는 할당 또는 이후 관련 ISO 639 등록 기관이나 관리 표준화 기구가 수행한 할당에 따라 정의되었다. A. "ISO 639-2:1998 - Codes for the representation of names of languages -- Part 2: Alpha-3 code - edition 1" [ISO639-2] Phillips & Davis 최선 현행 관행 [9쪽]
RFC 5646 언어 태그 2009년 9월 B. "ISO 639-3:2007 - Codes for the representation of names of languages -- Part 3: Alpha-3 code for comprehensive coverage of languages" [ISO639-3] C. "ISO 639-5:2008 - Codes for the representation of names of languages -- Part 5: Alpha-3 code for language families and groups" [ISO639-5] 3. 'qaa'부터 'qtz'까지 범위의 하위 태그는 언어 태그에서 사적 사용을 위해 예약되어 있다. 이러한 하위 태그는 ISO 639-2에서 사적 사용을 위해 예약한 코드에 대응한다. 이 코드는 등록되지 않은 기본 언어 하위 태그에 사용할 수 있다('x-' 뒤의 사적 사용 하위 태그를 사용하는 대신). 사적 사용 하위 태그에 대한 자세한 내용은 섹션 4.6을 참조한다. 4. 네 문자 언어 하위 태그는 가능한 향후 표준화를 위해 예약되어 있다. 5. IANA 등록소에서 길이가 다섯 자에서 여덟 자인 모든 언어 하위 태그는 섹션 3.5의 등록 절차를 통해 정의되었으며, 기본 언어 하위 태그를 구성하는 데 사용될 수 있다. 이러한 등록에 포함될 수 있는 예로는 조부 적용 IANA 등록 "i-enochian"이 있다. 하위 태그 'enochian'은 IANA 등록소에 기본 언어 하위 태그로 등록될 수 있으며(ISO 639가 이 언어를 먼저 등록하지 않는다고 가정할 때), 이로써 "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 Registration Authority Joint Advisory Committee(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'는 확장 언어 하위 태그 없이도 어떤 특정되지 않은 중국어 변종으로 리소스를 표시하는 데 여전히 사용될 수 있으며, 기본 언어 하위 태그('gan', 'yue', 'cmn')가 확장 언어 형식("zh-gan", "zh-yue", "zh-cmn")을 사용하는 것보다 선호된다. 2.2.3. 문자 체계 하위 태그 문자 체계 하위 태그는 언어 또는 그 방언의 문자 형태를 구별하는 문자 체계 또는 쓰기 체계의 변형을 나타내는 데 사용된다. 다음 규칙은 문자 체계 하위 태그에 적용된다. 1. 문자 체계 하위 태그는 모든 기본 및 확장 언어 하위 태그 뒤에 와야 하며, 다른 유형의 하위 태그보다 앞서야 한다. 2. 문자 체계 하위 태그는 네 글자로 구성되며, [ISO15924] ("Information and documentation -- Codes for the representation of names of scripts")에서 발견되는 할당 또는 이후 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] ("Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes")에서 발견되는 할당, 즉 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 Standard Country or Area Codes for Statistical Use [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)로 시작하는 변형 하위 태그는 길이가 최소 다섯 자여야 한다. Phillips & Davis 최선 현행 관행 [15쪽]
RFC 5646 언어 태그 2009년 9월 2. 숫자(0-9)로 시작하는 변형 하위 태그는 길이가 최소 네 자여야 한다. 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. 각 확장 하위 태그는 길이가 두 자에서 여덟 자 사이여야 하며, 문자 또는 숫자로만 구성되어야 하고, 각 하위 태그는 하나의 '-'로 분리되어야 한다. 다른 모든 언어 하위 태그와 마찬가지로 확장에서 대소문자 차이는 무시되며, 이 유형의 정규화된 하위 태그는 소문자일 것으로 기대된다. 6. 각 singleton 뒤에는 적어도 하나의 확장 하위 태그가 따라야 한다. 예를 들어 태그 "tlh-a-b-foo"는 첫 번째 singleton 'a' 바로 뒤에 또 다른 singleton 'b'가 오므로 유효하지 않다. 7. 확장 하위 태그는 태그 안에서 모든 기본 언어, 확장 언어, 문자 체계, 지역 및 변형 하위 태그 뒤에 와야 하며, 모든 사적 사용 하위 태그 시퀀스보다 앞서야 한다. 8. singleton 뒤와 또 다른 singleton 앞에 오는 모든 하위 태그는 확장의 일부이다. 예: 태그 "fr-a-Latn"에서 하위 태그 'Latn'은 IANA 언어 하위 태그 등록소에 정의된 문자 체계 하위 태그 'Latn'을 나타내지 않는다. 그 의미는 확장 'a'에 의해 정의된다. 9. 둘 이상의 확장이 하나의 태그에 나타나는 경우, 섹션 4.5에 설명된 대로 여러 확장 시퀀스를 대소문자를 구분하지 않는 ASCII 순서로 정렬하여 태그를 정규화하는 것이 좋다. 예를 들어 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에 정의된 형식 및 내용 제약을 준수해야 한다. 즉, 문자와 숫자로만 구성되어야 하며 길이가 여덟 자를 넘지 않아야 한다. 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-oed"를 제외하면, 이는 "en-GB"의 변형이며, 각 태그는 전체로서 하나의 언어를 나타낸다. 많은 조부 적용 태그는 이후 새 하위 태그가 추가됨으로써 대체되었다. 대체된 각 레코드에는 해당 값을 나타내는 언어 태그를 구성할 때 사용해야 하는 '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]의 생산식과 기능적으로 동등하지만, 기존 'grandfathered' 생산식에서 발생하는 특정 올바른 형식 오류를 방지하기 위해 Phillips & Davis 최선 현행 관행 [20쪽]
RFC 5646 언어 태그 2009년 9월 변경되었다. 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로 종료된다. 각 필드의 텍스트는 Unicode Normalization Form C(NFC)여야 한다. Phillips & Davis 최선 현행 관행 [21쪽]
RFC 5646 언어 태그 2009년 9월 필드 모음은 하나의 "레코드"를 이룬다. 레코드는 "%%" (U+0025 U+0025) 시퀀스만 포함하는 행으로 분리된다. 필드는 논리적으로는 하나의 텍스트 행이지만, 파일 형식의 각 텍스트 행은 길이가 72바이트로 제한된다. 이를 수용하기 위해 field-body는 여러 줄 표현으로 나눌 수 있다. 이를 "접기"라고 한다. 접기는 줄바꿈에 대한 관습적 관례에 따라 수행된다. 일반적으로 공백 경계에서 이루어지지만, 언어가 단어 사이에 공백을 사용하지 않는 경우처럼 값에 공백이 포함되지 않을 때는 다른 문자 사이에서도 발생할 수 있다. 어떤 경우에도 다중 바이트 UTF-8 시퀀스 내부나 결합 문자 시퀀스 중간에서 줄바꿈이 있어서는 안 된다. 자세한 내용은 [UAX14]를 참조한다. 파일 형식은 Unicode 문자 집합을 사용하고 파일 자체는 UTF-8 인코딩을 사용하지만, 특정 필드의 설명(섹션 3.1.2)에서 달리 표시되지 않는 한 필드는 US-ASCII [ISO646] 레퍼토리의 인쇄 가능한 문자로 제한된다. 등록소의 형식은 다음 ABNF [RFC5234]로 설명된다. 문자 번호 (코드 포인트)는 Unicode에서 가져오며, 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) ; Unicode 코드 포인트 그림 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"를 가진 필드를 포함한다는 점을 제외하면 동일한 구조를 가진다. Field-name은 레코드당 두 번 이상 나타나서는 안 되며, 'Description', 'Comments', 'Prefix' 필드는 예외이다. 각 레코드는 다음 필드 각각을 적어도 하나씩 포함해야 한다. 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"이며, 이는 "nan-Hant" 또는 "nan-TW"와 같은 태그의 Phillips & Davis 최선 현행 관행 [24쪽]
RFC 5646 언어 태그 2009년 9월 기반으로 사용될 수 있다("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' 필드는 Unicode 문자의 전체 범위를 포함할 수 있다. 적어도 하나의 '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'(Zaire)은 해당 국가의 이름이 변경되었을 때 하위 태그 'CD'(Democratic Republic of the Congo)로 대체되었다. 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' 유형 레코드에서는 대응하는 'Deprecated' 필드 없이 'Preferred-Value' 필드가 나타난다. 구현은 이러한 선호 값 매핑을 무시할 수 있지만, 매핑을 무시한다면 일관되게 그렇게 하는 것이 좋다. 또한 'Preferred-Value'를 매핑된 항목과 동등하게 취급하는 것이 좋다. 예를 들어 태그 "zh-yue-Hant-HK"와 "yue-Hant-HK"는 의미론적으로 동등하며 같은 태그인 것처럼 취급되어야 한다. 때때로 폐기된 코드가 특정 맥락에서는 선호된다. 예를 들어 "iw"와 "he"는 모두 Java 프로그래밍 언어에서 사용할 수 있지만, "he"는 입력 시 "iw"로 변환되며 따라서 Java에서는 "iw"가 정규 형식이다. Phillips & Davis 최선 현행 관행 [29쪽]
RFC 5646 언어 태그 2009년 9월 'region' 유형 레코드의 'Preferred-Value' 매핑은 때때로 원래 값과 정확히 같은 의미를 나타내지 않는다. 국가 코드가 변경되는 데에는 많은 이유가 있으며, 이것이 언어 태그 형성에 미치는 영향은 해당 변경의 성격에 따라 달라진다. 예를 들어 지역 하위 태그 'YD'(Democratic Yemen)는 두 나라가 1990년에 통일되었을 때 하위 태그 'YE'(Yemen)를 선호하여 폐기되었다. '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'가 'YY'의 'Preferred-Value'를 가진다고 가정하자. 나중에 'YY'가 'ZZ'의 'Preferred-Value'를 가지도록 변경된다면, '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' 필드를 가지고 있는 경우 등록 절차를 통해 'variant' 레코드에 추가될 수 있다. 각 '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은 "매크로언어"라는 용어를 "[...] 서로 구별되는 개별 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이 할당한 값만 포함 대상으로 고려된다. 'Macrolanguage' 필드는 ISO 639-3이 새 값을 정의하거나 이전 값을 철회할 때마다 일반 등록 절차를 통해 추가 또는 제거될 수 있다. 매크로언어는 정보 제공용이며, 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'(중국어)는 'macrolanguage'의 'Scope'를 가지며, 그 안에 포함된 언어 'nan'(민난 중국어)은 'individual'의 'Scope'를 가진다. 특수 값 'und'(미정)는 'special'의 'Scope'를 가진다. ISO 639-5 모음 'gem'(게르만어군)은 'collection'의 'Scope'를 가진다. 3.1.12. Comments 필드 필드 'Comments'는 레코드에 대한 추가 정보를 포함하며 레코드당 여러 번 나타날 수 있다. field-body는 Unicode 문자의 전체 범위를 포함할 수 있으며 특정 문자 체계로 제한되지 않는다. 이 필드는 등록 절차를 통해 삽입 또는 변경될 수 있으며, 안정성은 보장되지 않는다. 이 필드의 내용은 정보를 등록해야 할 필요성, 요청의 적합성 및 합리적인 실제 크기 제한을 제외하고 제한되지 않는다. '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이 할당한 코드 중 기존 두 글자 기본 언어 하위 태그와 충돌하지 않고 등록소에 정의된 대응 세 글자 기본 언어가 없는 코드는 'language' 유형의 새 레코드로 IANA 등록소에 입력된다. ISO 639-1 코드가 부여된 언어에는 매크로언어에 포함되더라도 확장 언어 하위 태그가 부여될 수 없다는 점에 유의한다. Phillips & Davis 최선 현행 관행 [37쪽]
RFC 5646 언어 태그 2009년 9월 B. ISO 639-3 또는 ISO 639-5가 할당한 코드 중 기존 세 글자 기본 언어 하위 태그와 충돌하지 않고 ISO 639-1 코드가 할당되지 않았거나 할당될 것으로 예상되지 않는 코드는 '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. ISO 639-2가 할당한 그 밖의 모든 코드 중 기존 세 글자 기본 또는 확장 언어 하위 태그와 충돌하지 않고 ISO 639-1 두 글자 코드가 할당되지 않은 코드는 'language' 유형의 새 레코드로 IANA 등록소에 입력된다. 이러한 유형의 등록은 향후 발생하지 않을 것으로 되어 있다. Phillips & Davis 최선 현행 관행 [38쪽]
RFC 5646 언어 태그 2009년 9월 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)에 의해 의미가 파생된 모든 하위 태그의 경우, 기존 코드에 새 의미가 할당되고 그 새 의미가 해당 코드의 의미를 넓힌다면, 관련 하위 태그의 의미는 이에 맞게 변경될 수 있다. 그러나 하위 태그의 의미는 좁혀져서는 안 된다. 이는 기존 하위 태그 사용 중 알 수 없는 비율이 유효하지 않게 될 수 있기 때문이다. 참고: 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에는 "countries and areas"(예: 독일을 나타내는 '276')와 "geographical regions and sub-regions"(예: 유럽을 나타내는 '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'를 선호하여 폐기되었다. 이러한 태그는 그 하위 태그 일부를 'variants'로 등록함으로써 '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에 설명된 안정성 규정의 적용을 받는 바와 같이 이 절차를 사용한다. 등록 요청은 섹션 3.4에 설명된 대로 하위 태그 레코드의 'Comments', 'Deprecated', 'Description', 'Prefix', 'Preferred-Value', 'Macrolanguage' 또는 'Suppress-Script' 필드의 정보와 관련하여 접수된다. IANA 등록소의 다른 모든 필드에 대한 변경은 허용되지 않는다. 새 하위 태그를 등록하거나 기존 태그 또는 하위 태그의 수정을 요청하는 일은 요청자가 아래에 재현된 등록 양식을 작성하는 것으로 시작된다. 각 응답은 크기에 제한되지 않으므로 요청은 등록 내용을 충분히 설명할 수 있다. "Record Requested" 섹션의 필드는 레코드가 승인되기 전에 섹션 3.1의 요구사항을 따라야 한다. LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: 2. E-mail address of requester: 3. Record Requested: Type: Subtag: Description: Prefix: Preferred-Value: Deprecated: Suppress-Script: Macrolanguage: Comments: 4. Intended meaning of the subtag: 5. Reference to published description of the language (book or article): 6. Any other relevant information: 그림 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 인코딩을 사용하는 것이 좋다. 그러나 일부 메일 클라이언트가 이 인코딩을 지원하지 않으므로 등록 요청에는 다른 인코딩도 사용될 수 있다. 언어 하위 태그 검토자는 보관된 요청 양식과 등록소 레코드 모두에 올바른 Unicode 문자가 나타나도록 할 책임이 있다. IANA의 전사 또는 인코딩 오류가 있는 경우, 언어 하위 태그 검토자는 IANA를 돕는 데 필요한 정보를 제공하여 등록소 수정을 요청할 것이다. 확장 언어 하위 태그('extlang' 유형)는 정의상 항상 다른 언어에 포괄된다. 따라서 'extlang' 유형의 모든 레코드는 등록 시점에 'Prefix' 필드를 포함해야 한다. 이 'Prefix' 필드는 결코 변경되거나 제거될 수 없으며, 이를 요청하는 경우 거부되어야 한다. 변형 하위 태그는 일반적으로 특정 범위의 언어 태그와 함께 사용하도록 등록되며, 적용 대상 언어의 용어에 기반한 변형 하위 태그가 권장된다. 예를 들어 하위 태그 'rozaj'(Resian)는 기본 언어 하위 태그 "sl"(슬로베니아어)로 시작하는 언어 태그와 함께 사용하기 위한 것이다. Resian은 슬로베니아어의 방언이기 때문이다. 따라서 하위 태그 'rozaj'는 "sl-Latn-rozaj" 또는 "sl-IT-rozaj"와 같은 태그에 적절할 것이다. 이 정보는 등록소의 'Prefix' 필드에 저장된다. 변형 Phillips & Davis 최선 현행 관행 [43쪽]
RFC 5646 언어 태그 2009년 9월 등록 요청은 등록 양식에 적어도 하나의 'Prefix' 필드를 포함하는 것이 좋다. 기존 하위 태그 값을 가진 같은 유형의 추가 레코드 할당 요청은 거부되어야 한다. 예를 들어 변형 하위 태그 'rozaj'는 이미 등록소에 존재하므로, 하위 태그 'rozaj'를 가진 두 번째 'variant' 유형 레코드를 추가하는 것은 금지된다. 특정 등록된 변형 하위 태그의 'Prefix' 필드는 IANA 등록소에서 사용 안내로 존재한다. 추가 'Prefix' 필드는 추가 등록 양식을 제출함으로써 추가될 수 있다. 그 양식에서 "Any other relevant information:" 필드는 그것이 접두사의 추가임을 나타내야 한다. 다른 의미론적 의미를 암시하는 'Prefix' 필드를 변형 하위 태그에 추가하려는 요청은 거부되는 것이 좋다. 예를 들어 태그 "de-1994"가 어떤 독일어 방언이나 철자 형태를 나타내도록 하위 태그 '1994'에 접두사 "de"를 추가하라는 요청은 거부될 것이다. '1994' 하위 태그는 특정 슬로베니아어 철자법을 나타내며, 추가 등록은 하위 태그에 할당된 의미론적 의미를 변경하거나 흐리게 만들 것이다. 대신 별도의 하위 태그를 제안하는 것이 좋다. 현재 'Prefix' 필드가 없는 변형 하위 태그에 'Prefix'를 추가하라는 요청은 거부되어야 한다. 변형은 많은 언어 또는 심지어 모든 언어에 잠재적으로 유용하기 때문에 접두사 없이 등록된다. 하나 이상의 'Prefix' 필드를 추가하는 것은 변형의 사용에 잠재적으로 해로울 수 있다. 이는 하위 태그의 범위를 극적으로 줄이기 때문이다(이는 안정성 규칙(섹션 3.4)에 따라 허용되지 않으며, 'Prefix'의 추가가 일반적으로 하는 일인 하위 태그 범위의 확대와는 반대이다). 이러한 "no-prefix" 변형의 예는 국제 음성 기호를 나타내는 하위 태그 'fonipa'이며, 이는 많은 언어를 전사하는 데 사용할 수 있는 체계이다. 요청에 제공되는 'Description' 필드는 라틴 문자로 작성되거나 전사된 설명을 적어도 하나 포함해야 한다. 요청은 어떤 문자 체계나 언어로 된 추가 'Description' 필드도 포함할 수 있다. 'Description' 필드는 식별 목적으로 사용되며, 반드시 언어나 변형의 실제 고유 이름을 나타내는 것은 아니다. 또한 특정 언어로 되어 있을 필요는 없지만, 레코드의 항목을 식별하기에 적합하고 충분한 것이 좋다. 언어 하위 태그 검토자는 고유성을 보장하고 같은 유형의 다른 레코드에 있는 'Description' 필드와의 충돌을 방지하기 위해 제안된 'Description' 필드를 확인하고 편집할 것이다. 이것이 독립 등록 요청에서 발생하면, 요청의 유일한 목적이 중복 'Description' 필드를 도입하는 것이 아닌 한, 언어 하위 태그 검토자는 섹션 3.5에 설명된 대로 논의로 인한 요청 수정으로 취급하여 해당 레코드를 <ietf-languages@iana.org>에 다시 제출해야 하며, Phillips & Davis 최선 현행 관행 [44쪽]
RFC 5646 언어 태그 2009년 9월 그러한 경우 요청은 거부되어야 한다. '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]에 이의 제기될 수 있다. 여기에는 검토 기간을 연장하는 결정이나 명확하고 적시에 결정을 발표하지 못한 경우도 포함된다. 승인된 레코드는 언어 하위 태그 등록소에 나타난다. 승인된 등록 양식은 http://www.iana.org에서 온라인으로 제공된다. 기존 레코드에 대한 갱신 또는 변경은 새 등록과 같은 절차를 따른다. 언어 하위 태그 검토자는 2주 검토 기간 후 등록을 갱신할 합의가 있는지 결정한다. 일반적으로 원래 등록자의 반대는 그러한 합의를 형성하는 데 추가적인 비중을 가진다. 등록은 영구적이고 안정적이다. 일단 등록되면 하위 태그는 등록소에서 제거되지 않으며 특정 언어 또는 변형을 지정하는 유효한 방법으로 남는다. 참고: 등록 양식의 "Reference to published description" 섹션의 목적은 어떤 언어가 등록되어 있는지 또는 특정 하위 태그가 어떤 언어나 언어 변형을 가리키는지 검증하는 데 도움을 주는 것이다. 대부분의 경우 해당 언어의 권위 있는 문법서나 사전에 대한 참조가 유용할 것이다. 그러한 저작이 없는 경우, 해당 언어를 설명하거나 해당 언어로 된 다른 잘 알려진 저작이 적절할 수 있다. 언어 하위 태그 검토자는 어떤 자료가 "충분히 좋은" 참조 자료인지를 결정한다. 이 요구사항은 화자 수가 적거나 표준화된 철자법이 없다는 이유로 특정 언어나 방언을 배제하려는 것이 아니다. 소수 언어는 그 자체의 장점에 따라 동등하게 고려될 것이다. 3.6. 등록 가능성 하위 태그 또는 하위 태그에 관한 정보의 등록 가능성에는 다음이 포함된다. o ISO 639에 나열되지 않았고 나열되거나 등록된 어떤 언어의 변형도 아닌 언어에 대한 기본 언어 하위 태그는 등록될 수 있다. 이 문서가 작성된 시점에는 이러한 형식의 하위 태그 예가 없었다. 언어 하위 태그를 등록하려고 시도하기 전에, 해당 언어를 ISO Phillips & Davis 최선 현행 관행 [46쪽]
RFC 5646 언어 태그 2009년 9월 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 Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72 ISO 639-2는 ISO 639-2의 언어 목록에 대한 추가 및 변경을 위한 등록 기관을 정의한다. 이 기관은 다음과 같다. Library of Congress Network Development and MARC Standards Office Washington, DC 20540, USA Phone: +1 202 707 6237 Fax: +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 Phone: +1 972 708 7400, ext. 2293 Fax: +1 972 708 7546 Email: 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 Phone: +1 202 707 6237 Fax: +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 Phone: +41 22 749 72 33 Fax: +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 United Nations Secretariat의 Statistics Division은 Standard Country or Area Codes for Statistical Use를 유지 관리하며, 다음으로 연락할 수 있다. Statistical Services Branch Statistics Division United Nations, Room DC2-1620 New York, NY 10017, USA Fax: +1-212-963-0623 Email: 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월 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'는 OPTIONAL 필드이며 확장에 대한 더 넓은 설명을 포함할 수 있다. '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 이는 언어 협상을 수행할 때 적절한 fallback 선택에 관한 정보를 포함하지 않는다. 좋은 fallback 언어는 지정된 언어와 언어학적으로 관련이 없을 수도 있다. 한 언어가 다른 언어의 fallback 언어로 자주 사용된다는 사실은 일반적으로 지리, 역사 또는 문화와 같은 외부 요인의 결과이며, 이러한 요인은 모든 경우에 적용되지 않을 수 있다. 예를 들어 Breton(프랑스 북서부에서 사용되는 켈트어)을 사용하는 대부분의 사람들은 Breton이 제공되지 않는 경우 아마도 French(로망스어)를 제공받는 것을 선호할 것이다. 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')를 나타내며, Swiss High German(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"(Hakka) 및 "zh-guoyu"(Mandarin 또는 Standard Chinese) 태그가 포함된다. 수화 언어는 언어적 유산이 아니라 의사소통 방식을 공유한다. 독립적으로 발전한 수화 언어가 많이 있으며, 하위 태그 'sgn'은 수화 언어의 존재만을 나타낸다. 여러 수화 언어도 RFC 3066 시대에 조부 적용 태그를 등록받았다. 예를 들어 조부 적용 태그 "sgn-US"는 미국을 참조하지 않고 구체적으로 'American Sign Language'를 나타내도록 등록되었다. 이는 여전히 유효하지만 폐기되었다. 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의 경우, 언어 태그는 로캘 식별자의 대부분 구현에 대한 기반을 이룬다. 예를 들어 Unicode의 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. 길이 고려 사항 언어 태그의 크기에 대해 정의된 상한은 없다. 역사적으로 대부분의 언어 태그가 총 길이 최대 여섯 자의 언어 및 지역 하위 태그로 구성되었지만, 더 큰 태그는 항상 가능했고 실제로 사용되어 왔다. 언어 태그 구문이나 이 문서의 다른 요구사항은 언어 태그의 하위 태그 수(따라서 태그 크기의 상한)에 고정된 상한을 부과하지 않는다. 언어 태그 구문은 특정 언어에 따라 어떤 애플리케이션에서 언어를 완전히 식별하기 위해 더 많은 하위 태그(따라서 더 긴 태그)가 때때로 필요함을 시사한다. 따라서 길거나 복잡한 하위 태그 시퀀스를 상상할 수 있다. Phillips & Davis 최선 현행 관행 [63쪽]
RFC 5646 언어 태그 2009년 9월 4.4.1. 제한된 버퍼 크기로 작업하기 일부 애플리케이션과 프로토콜은 고정 버퍼 크기를 할당하거나 언어 태그의 길이를 다른 방식으로 제한해야 한다. 적합한 구현 또는 명세는 지정된 길이를 초과하는 언어 태그의 저장을 지원하지 않을 수 있다. 그러한 제한은 명확히 문서화하는 것이 좋으며, 그러한 문서에는 더 긴 태그에 어떤 일이 발생하는지(예: 오류 값이 생성되는지 또는 언어 태그가 절단되는지)가 포함되는 것이 좋다. 임의의 한계에서 태그가 절단되도록 허용하면서 그 한계가 무엇인지에 대한 표시를 제공하지 않는 프로토콜은 태그의 의미를 실질적으로 변경함으로써 해를 끼칠 가능성이 있다. 실제로 대부분의 언어 태그는 몇 개 이상의 하위 태그를 필요로 하지 않으며, 합리적인 크기의 버퍼 제한에 접근하지도 않을 것이다. 섹션 4.1을 참조한다. 일부 명세나 프로토콜에는 태그 길이에 대한 제한이 있지만 고정 길이 제한은 없다. 예를 들어 [RFC2231]에는 명시적인 길이 제한이 없다. 언어 태그에 사용할 수 있는 길이는 [RFC2047]의 76자 제한과 결합된 다른 헤더 구성 요소(예: charset 이름)의 길이에 의해 제약된다. 따라서 "한계"는 50자 이상일 수 있지만 잠재적으로는 상당히 작을 수도 있다. 버퍼 한계를 할당할 때의 고려 사항은 다음과 같다. 구현은 태그의 의미를 의도적으로 변경하려는 경우나, 저장 또는 전송을 위해 프로토콜이 지정한 제한된 버퍼 크기에 태그가 맞지 않는 경우가 아니라면 언어 태그를 절단하지 않는 것이 좋다. 절단은 태그의 의미론적 의미를 변경하므로, 구현은 태그가 절단될 때 사용자에게 경고하는 것이 좋다. 공간 제약이 있지만 고정 한계가 없는 프로토콜 또는 명세의 구현은 절단보다 가능한 한 가장 긴 태그를 사용하는 것이 좋다. 언어 태그에 제한된 버퍼 크기를 지정하는 프로토콜 또는 명세는 최소 35자의 언어 태그를 허용해야 한다. [RFC4646]은 'extlang' 생산식의 세 요소를 모두 포함했기 때문에 최소 필드 크기로 42자를 권장했다는 점에 유의한다. 이들 중 두 개는 이제 영구적으로 예약되어 있으므로, 최대 길이 8자의 등록된 기본 언어 하위 태그가 이제 가장 긴 language-extlang 조합보다 더 길다. 확장 또는 사적 사용 하위 태그를 일반적으로 사용하는 프로토콜이나 명세는 더 긴 "최소 버퍼" 크기를 예약하거나 권장하고자 할 수 있다. Phillips & Davis 최선 현행 관행 [64쪽]
RFC 5646 언어 태그 2009년 9월 다음 그림은 35자 권장이 어떻게 도출되었는지 보여준다. language = 8 ; 허용되는 가장 긴 등록 값 ; 7자가 필요한 primary+extlang보다 김 script = 5 ; 억제되지 않는 경우: 섹션 4.1 참조 region = 4 ; UN M.49 숫자 지역 코드 ; ISO 3166-1 코드는 3자가 필요 variant1 = 9 ; 접두사로 'language'가 필요 variant2 = 9 ; 매우 드묾, 접두사로 ; 'language-variant1'이 필요하기 때문 total = 35 characters 그림 7: 태그 길이 한계의 도출 4.4.2. 언어 태그의 절단 언어 태그의 절단은 태그의 의미를 변경하므로 피하는 것이 좋다. 그러나 제한된 버퍼 크기 때문에 언어 태그의 절단이 때때로 필요하다. 그러한 절단은 하위 태그가 중간에서 잘리거나 유효하지 않은 태그 (예: "-" 문자로 끝나는 태그)가 형성되도록 허용해서는 안 된다. 이는 태그를 절단하는 애플리케이션이나 프로토콜이 언어 태그의 오른쪽에서 하위 태그와 그 앞의 "-"를 함께 점진적으로 제거하여, 태그가 주어진 버퍼에 충분히 짧아질 때까지 그렇게 해야 함을 의미한다. 결과 태그가 단일 문자 하위 태그로 끝나는 경우, 그 하위 태그와 그 앞의 "-"도 제거해야 한다. 예: Tag to truncate: 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"(중국어, Hakka)은 하위 태그 'hak' (Hakka)으로 대체된다. * 대부분의 비-extlang 하위 태그는 국가 이름 또는 명칭이 변경된 지역 하위 태그이거나 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"(Hakka, China)은 기본 언어 하위 태그 'hak'를 가지며, 이는 다시 'Prefix' 'zh'(Chinese)를 가진 'extlang' 레코드를 가진다. extlang 형식은 "zh-hak-CN" (Chinese, Hakka, China)이다. * 2단계(접두사 앞붙이기)는 1단계(정규화)에서 제거된 하위 태그를 복원할 수 있다는 점에 유의한다. 예: 언어 태그 "en-a-aaa-b-ccc-bbb-x-xyz"는 정규 형식에 있지만, "en-b-ccc-bbb-a-aaa-X-xyz"는 올바른 형식이고 잠재적으로 유효하다 (확장 'a'와 'b'는 이 문서 발행 시점에는 정의되어 있지 않음). 그러나 확장이 알파벳순이 아니므로 정규 형식은 아니다. 예: 태그 "en-BU"(Burma에서 사용되는 영어)는 유효성을 유지하지만, 언어 태그 "en-BU"는 정규 형식이 아니다. 'BU' 하위 태그가 'MM' (Myanmar)으로의 정규 매핑을 가지기 때문이다. 언어 태그의 정규화는 하위 태그를 처리하거나 비교할 때 대문자나 소문자의 사용에 대해 아무것도 암시하지 않는다(섹션 2.1에 설명된 바와 같음). 모든 비교는 대소문자를 구분하지 않는 방식으로 수행해야 한다. 언어 태그를 정규화할 때, 처리기는 등록소에서 사용된 대소문자를 따라 하위 태그의 대소문자를 규칙화할 수 있다(즉, 이 과정은 OPTIONAL이다). 섹션 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으로 도입되는 사적 사용 시퀀스는 사적 사용 합의 밖의 사용자나 구현에는 완전히 불투명하다. 따라서 Language Subtag Registry는 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에 의해 처음 게시된 날짜여야 한다. 하루에 게시되는 등록소 버전은 많아야 하나여야 한다. 'File-Date' 레코드는 IANA에 레코드 삽입 또는 수정을 요청할 때마다 포함되며, 요청에 포함된 레코드의 승인 날짜를 나타낸다. 갱신된 등록소 파일은 UTF-8 문자 인코딩을 사용해야 하며, IANA는 등록소 파일의 올바른 인코딩을 확인해야 한다. 비ASCII 문자는 등록 양식을 이메일 메시지에 첨부하거나 메일 메시지 본문에서 여러 인코딩을 사용하여 IANA에 보낼 수 있다(UTF-8이 권장된다). IANA는 갱신된 등록소를 게시하기 전에 불명확하거나 손상된 문자를 언어 하위 태그 검토자와 확인할 것이다. IANA는 또한 각 등록 양식을 http://www.iana.org에서 보관하고 공개적으로 제공할 것이다. 여러 등록이 등록소의 같은 레코드와 관련될 수 있다는 점에 유의한다. Language Subtag Registry에 의존하는 개발자는 때때로 구현을 갱신할 수 있도록 등록소의 변경 사항을 통지받고자 한다. Language Subtag Registry에 변경이 이루어질 때, IANA는 <ietf-languages-announcements@iana.org> (IANA만 게시할 수 있는 자체 구독 목록)로 공지 메시지를 보낼 것이다. Phillips & Davis 최선 현행 관행 [70쪽]
RFC 5646 언어 태그 2009년 9월 5.2. 확장 등록소 Language Tag Extensions Registry는 많아야 35개의 레코드를 포함할 수 있으므로, 이 등록소의 변경은 매우 드물 것으로 예상된다. Language Tag Extensions Registry에 대한 IANA의 향후 작업은 두 가지 경우로 제한된다. 첫째, IESG는 때때로 새 레코드를 이 등록소에 삽입하도록 요청할 수 있다. 이러한 요청은 섹션 3.7에 설명된 정확한 형식으로 삽입할 레코드를 포함해야 한다. 또한 특정 확장의 유지 관리 기관이 레코드의 연락처 정보나 URL을 갱신하도록 요청하는 경우가 가끔 있을 수 있다. 이러한 요청은 완전하고 갱신된 레코드를 포함해야 한다. IANA는 제공된 정보가 올바르게 형식화되었는지만 책임지며, 정보를 검증할 책임은 없다. IANA는 요청이 등록소에 있는 레코드에 명명된 유지 관리 기관에서 온 것인지 확인하기 위해 합리적인 조치를 취하는 것이 좋다. 6. 보안 고려 사항 콘텐츠 협상에 사용되는 언어 태그는 인터넷에서 교환되는 다른 모든 정보와 마찬가지로 우려의 원천이 될 수 있다. 이는 발신자의 국적을 추론하는 데 사용될 수 있고, 따라서 감시의 잠재적 대상을 식별할 수 있기 때문이다. 이는 전송되는 모든 것이 수신 당사자에게, 그리고 어쩌면 제3자에게도 보일 수 있다는 일반적 문제의 특수한 경우이다. 그러한 우려가 일부 경우에 존재할 수 있음을 인식하는 것은 유용하다. 위협의 정확한 규모 평가와 가능한 대응책은 각 애플리케이션 프로토콜에 맡겨진다(보안 위협과 방어에 대한 최선 현행 관행 지침은 BCP 72 [RFC3552] 참조). 특정 정보 항목과 관련된 언어 태그는 그 콘텐츠가 가능한 동형이의자 (homograph)를 포함할 수 있는지 판단하는 데 전혀 영향을 미치지 않는다. 텍스트가 어떤 언어로 되어 있거나 특정 문자 체계 하위 태그를 사용한다고 태그 지정되어 있다는 사실은, 해당 언어 태그와 관련되거나 지정된 문자 체계 이외의 문자에서 온 문자를 포함하지 않는다는 보장을 전혀 제공하지 않는다. 변형, 사적 사용 및 확장 하위 태그의 수에는 제한이 없고, 결과적으로 태그의 가능한 길이에도 제한이 없으므로, 구현은 버퍼 오버플로 공격을 방어해야 한다. 버퍼 오버플로 방어의 결과로 발생할 수 있는 언어 태그 절단에 대한 자세한 내용은 섹션 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에 "collections"에 관한 단락을 추가했다. o 섹션 3.1에서 'Tag' 필드의 대문자화 규칙을 변경했다. o 섹션 3.1을 하위 섹션으로 나누었다. o 등록 절차를 통해 'Suppress-Script' 필드를 추가, 수정 또는 제거할 수 있도록 섹션 3.5를 수정했다. 이는 RFC 4646의 정오표였다. o 지역 코드 'CS'(이전 Serbia and Montenegro)를 사용하던 예를 'RS'(Serbia)를 사용하도록 수정했다. Phillips & Davis 최선 현행 관행 [73쪽]
RFC 5646 언어 태그 2009년 9월 o 중복 설명, 역전된 중복을 포함한 중복을 방지하도록 레코드 'Description' 필드 생성 및 유지 관리 규칙을 수정했다. o 이 섹션에서 RFC 4646이 만들어진 이유에 대한 긴 설명을 제거했으며, 이로 인해 XML Schema에 대한 참조도 제거되었다. o 언어 태그가 대소문자를 구분하지 않는다는 사실을 더 강조하도록 섹션 2.1의 텍스트를 수정했다. o 섹션 2.1의 예 "fr-Latn-CA"를 "sr-Latn-RS" 및 "az-Arab-IR"로 대체했다. "fr-Latn-CA"는 'fr'과 함께 'Latn'의 'Suppress-Script'를 존중하지 않기 때문이다. o 섹션 2.2.9에서 singleton 반복 검사를 올바른 형식 검사에서는 선택 사항으로 만들고(유효성 검사에는 필요함), 올바른 형식에 대한 요구사항을 변경했다. o 섹션 2.2.9에서 조부 적용 검사에 관한 텍스트를 변경하여 목록이 이제 ABNF에 포함되어 있음을 언급했다. o 섹션 3.2의 텍스트를 수정하고 추가했다. 직무 설명을 먼저 배치했다. Language Subtag Reviewer가 목록 조정을 포함한 여러 비핵심 업무를 위임할 수 있음을 명확히 하는 참고를 추가했다. 마지막으로 임명 절차를 명확히 하고 검토자의 결정과 수행에 이의 제기할 수 있음을 명확히 하는 추가 텍스트를 넣었다. 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와 Language Subtag Reviewer에 대한 추가 지침도 수반한다. o 'UK' 이외의 "exceptionally reserved" ISO 3166-1 코드가 등록소에 포함되도록 섹션 2.2.4의 규칙을 수정했다. 특히 이는 코드 'EU'(European Union)가 언어 태그를 구성하는 데 사용되거나 (더 일반적으로) 등록소를 지역 코드에 사용하는 애플리케이션이 이 하위 태그를 참조할 수 있게 한다. o 불필요한 규범적 [RFC2119] 언어를 제거하기 위해 IANA 고려 사항 섹션(섹션 5)을 수정했다. 9. 참고문헌 9.1. 규범적 참고문헌 [ISO15924] International Organization for Standardization, "ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts", January 2004. [ISO3166-1] International Organization for Standardization, "ISO 3166-1:2006. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", November 2006. [ISO639-1] International Organization for Standardization, "ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code", July 2002. [ISO639-2] International Organization for Standardization, "ISO 639-2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code", October 1998. [ISO639-3] International Organization for Standardization, "ISO 639-3:2007. Codes for the representation of names of languages - Part 3: Alpha-3 code for comprehensive coverage of languages", February 2007. Phillips & Davis 최선 현행 관행 [76쪽]
RFC 5646 언어 태그 2009년 9월 [ISO639-5] International Organization for Standardization, "ISO 639-5:2008. Codes for the representation of names of languages -- Part 5: Alpha-3 code for language families and groups", May 2008. [ISO646] International Organization for Standardization, "ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.", 1991. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [SpecialCasing] The Unicode Consoritum, "Unicode Character Database, Special Casing Properties", March 2008, <http:// unicode.org/Public/UNIDATA/SpecialCasing.txt>. [UAX14] Freitag, A., "Unicode Standard Annex #14: Line Breaking Properties", August 2006, <http://www.unicode.org/reports/tr14/>. [UN_M.49] Statistics Division, United Nations, "Standard Country or Area Codes for Statistical Use", Revision 4 (United Nations publication, Sales No. 98.XVII.9, June 1999. Phillips & Davis 최선 현행 관행 [77쪽]
RFC 5646 언어 태그 2009년 9월 [Unicode] Unicode Consortium, "The Unicode Consortium. The Unicode Standard, Version 5.0, (Boston, MA, Addison- Wesley, 2003. ISBN 0-321-49081-0)", January 2007. 9.2. 정보 제공 참고문헌 [CLDR] "The Common Locale Data Repository Project", <http://cldr.unicode.org>. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, January 2001. [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. Phillips & Davis 최선 현행 관행 [78쪽]
RFC 5646 언어 태그 2009년 9월 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4645] Ewell, D., "Initial Language Subtag Registry", RFC 4645, September 2006. [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. [RFC5645] Ewell, D., Ed., "Update to the Language Subtag Registry", September 2009. [UTS35] Davis, M., "Unicode Technical Standard #35: Locale Data Markup Language (LDML)", December 2007, <http://www.unicode.org/reports/tr35/>. [iso639.prin] ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory Committee: Working principles for ISO 639 maintenance", March 2000, <http://www.loc.gov/ standards/iso639-2/iso639jac_n3r.html>. [record-jar] Raymond, E., "The Art of Unix Programming", 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. 등록 양식의 예 LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: Han Steenwijk 2. E-mail address of requester: han.steenwijk @ unipd.it 3. Record Requested: Type: variant Subtag: biske Description: The San Giorgio dialect of Resian Description: The Bila dialect of Resian Prefix: sl-rozaj Comments: The dialect of San Giorgio/Bila is one of the four major local dialects of Resian 4. Intended meaning of the subtag: San Giorgio/Bila에서 사용되는 Resian의 지역 변종 5. Reference to published description of the language (book or article): -- Jan I.N. Baudouin de Courtenay - Opyt fonetiki rez'janskich govorov, Varsava - Peterburg: Vende - Kozancikov, 1875. Phillips & Davis 최선 현행 관행 [82쪽]
RFC 5646 언어 태그 2009년 9월 LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: Jaska Zedlik 2. E-mail address of requester: jz53 @ zedlik.com 3. Record Requested: Type: variant Subtag: tarask Description: Belarusian in Taraskievica orthography Prefix: be Comments: The subtag represents Branislau Taraskievic's Belarusian orthography as published in "Bielaruski klasycny pravapis" by Juras Buslakou, Vincuk Viacorka, Zmicier Sanko, and Zmicier Sauka (Vilnia-Miensk 2005). 4. Intended meaning of the subtag: 이 하위 태그는 Juras Buslakou, Vincuk Viacorka, Zmicier Sanko 및 Zmicier Sauka의 "Bielaruski klasycny pravapis"(Vilnia-Miensk 2005)에 게시된 벨라루스어 철자법을 나타내기 위한 것이다. 5. Reference to published description of the language (book or article): Taraskievic, Branislau. Bielaruskaja gramatyka dla skol. Vilnia: Vyd. "Bielaruskaha kamitetu", 1929, 5th edition. Buslakou, Juras; Viacorka, Vincuk; Sanko, Zmicier; Sauka, Zmicier. Bielaruski klasycny pravapis. Vilnia-Miensk, 2005. 6. Any other relevant information: 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, and many, many others. 이 문서가 가능하도록 해 준 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 (editor) Lab126 EMail: addison@inter-locale.com URI: http://www.inter-locale.com Mark Davis (editor) Google EMail: markdavis@google.com Phillips & Davis 최선 현행 관행 [84쪽]