Network Working Group M. Duerst
Request for Comments: 3987 W3C
Category: Standards Track M. Suignard
Microsoft Corporation
January 2005
Internationalized Resource Identifiers (IRIs)
이 메모의 상태
이 문서는 인터넷 커뮤니티를 위한 인터넷 표준 트랙 프로토콜을
명시하며, 개선을 위한 논의와 제안을 요청한다. 이 프로토콜의
표준화 상태와 현황은 "Internet Official Protocol Standards"
(STD 1)의 최신판을 참조하기 바란다. 이 메모의 배포에는
제한이 없다.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
이 문서는 Uniform Resource Identifier (URI)를 보완하는 새로운
프로토콜 요소인 Internationalized Resource Identifier (IRI)를
정의한다. IRI는 Universal Character Set (Unicode/ISO 10646)의
문자 시퀀스이다. IRI에서 URI로의 매핑이 정의되어 있으며, 이는
적절한 경우 리소스를 식별하기 위해 URI 대신 IRI를 사용할 수
있음을 의미한다.
URI의 정의를 확장하거나 변경하는 대신 새로운 프로토콜 요소를
정의하는 접근 방식이 선택되었다. 이는 명확한 구분을 가능하게
하고 기존 소프트웨어와의 비호환성을 피하기 위한 것이다. 현재
URI를 다루는 여러 프로토콜, 형식 및 소프트웨어 구성 요소에서
IRI를 사용하고 배포하기 위한 지침이 제공된다.
Table of Contents
1. 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 개요 및 동기 . . . . . . . . . . . . . . . . . . . . 3
1.2. 적용 가능성 . . . . . . . . . . . . . . . . . . . . 3
1.3. 정의 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. 표기법 . . . . . . . . . . . . . . . . . . . . . . . 5
2. IRI 구문 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. IRI 구문 요약 . . . . . . . . . . . . . . . . . . . 6
2.2. IRI 참조와 IRI를 위한 ABNF . . . . . . . . . . . . . 7
Duerst & Suignard Standards Track [Page 1]
RFC 3987 Internationalized Resource Identifiers January 2005
3. IRI와 URI의 관계 . . . . . . . . . . . . . . . . . . . . . 10
3.1. IRI에서 URI로의 매핑 . . . . . . . . . . . . . . . . 10
3.2. URI를 IRI로 변환 . . . . . . . . . . . . . . . . . . 14
3.2.1. 예시 . . . . . . . . . . . . . . . . . . . . 15
4. 오른쪽에서 왼쪽으로 쓰는 언어를 위한 양방향 IRI. . . . . 16
4.1. 논리적 저장과 시각적 표현 . . . . . . . . . . . . . 17
4.2. Bidi IRI 구조 . . . . . . . . . . . . . . . . . . . . 18
4.3. Bidi IRI 입력 . . . . . . . . . . . . . . . . . . . . 19
4.4. 예시 . . . . . . . . . . . . . . . . . . . . . . . . 19
5. 정규화와 비교 . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. 동등성 . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. 비교 준비 . . . . . . . . . . . . . . . . . . . . . . 22
5.3. 비교 사다리 . . . . . . . . . . . . . . . . . . . . 23
5.3.1. 단순 문자열 비교 . . . . . . . . . . . . . . 23
5.3.2. 구문 기반 정규화 . . . . . . . . . . . . . . 24
5.3.3. 스킴 기반 정규화 . . . . . . . . . . . . . . 27
5.3.4. 프로토콜 기반 정규화 . . . . . . . . . . . . 28
6. IRI의 사용 . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. IRI에서 허용되는 UCS 문자에 대한 제한 . . . . . . 29
6.2. 소프트웨어 인터페이스와 프로토콜 . . . . . . . . . 29
6.3. 문서와 프로토콜에서 URI와 IRI의 형식 . . . . . . . 30
6.4. 원래 문자를 인코딩하기 위한 UTF-8 사용 .. . . . . 30
6.5. 상대 IRI 참조 . . . . . . . . . . . . . . . . . . . 32
7. URI/IRI 처리 지침 (정보 제공) . . . . . . . . . . . . . . 32
7.1. URI/IRI 소프트웨어 인터페이스 . . . . . . . . . . . 32
7.2. URI/IRI 입력 . . . . . . . . . . . . . . . . . . . . 33
7.3. 애플리케이션 간 URI/IRI 전달 . . . . . . . . . . . 33
7.4. URI/IRI 생성 . . . . . . . . . . . . . . . . . . . . 34
7.5. URI/IRI 선택 . . . . . . . . . . . . . . . . . . . . 34
7.6. URI/IRI 표시 . . . . . . . . . . . . . . . . . . . . 35
7.7. URI와 IRI의 해석 . . . . . . . . . . . . . . . . . 36
7.8. 업그레이드 전략 . . . . . . . . . . . . . . . . . . 36
8. 보안 고려 사항 . . . . . . . . . . . . . . . . . . . . . 37
9. 감사의 말 . . . . . . . . . . . . . . . . . . . . . . . . 39
10. 참고 문헌 . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. 규범 참고 문헌 . . . . . . . . . . . . . . . . . . . 40
10.2. 정보 제공 참고 문헌 . . . . . . . . . . . . . . . . 41
A. 설계 대안 . . . . . . . . . . . . . . . . . . . . . . . . 44
A.1. 새로운 스킴 . . . . . . . . . . . . . . . . . . . . 44
A.2. UTF-8 이외의 문자 인코딩 . . . . . . . . . . . . . 44
A.3. 새로운 인코딩 규약 . . . . . . . . . . . . . . . . 44
A.4. URI/IRI에서 문자 인코딩 표시 . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 46
Duerst & Suignard Standards Track [Page 2]
RFC 3987 Internationalized Resource Identifiers January 2005
1. 소개
1.1. 개요 및 동기
Uniform Resource Identifier (URI)는 [RFC3986]에서
US-ASCII [ASCII] 문자 레퍼토리의 제한된 부분집합에서 선택된
문자 시퀀스로 정의된다.
URI의 문자는 자연어의 단어를 표현하는 데 자주 사용된다.
이러한 사용에는 많은 장점이 있다. 그런 URI는 기억하기 쉽고,
해석하기 쉽고, 옮겨 적기 쉽고, 만들기 쉽고, 추측하기 쉽다.
그러나 영어 이외 대부분의 언어에서 자연 문자 체계는 A - Z
이외의 문자를 사용한다. 많은 사람에게 라틴 문자를 다루는 것은
라틴 알파벳만 사용하는 사람들이 다른 문자 체계의 문자를
다루는 것만큼 어렵다. 비라틴 문자 체계를 가진 많은 언어는
라틴 문자로 전사된다. 이러한 전사는 현재 URI에서 자주
사용되지만, 추가적인 모호성을 유발한다.
지역 문자 체계의 문자를 적절히 처리하기 위한 인프라는 이제
운영 체제와 애플리케이션 소프트웨어의 지역화 버전에 널리
배포되어 있다. 다양한 문자 체계와 언어를 동시에 처리할 수 있는
소프트웨어도 점점 더 일반화되고 있다. 또한 점점 더 많은
프로토콜과 형식이 넓은 범위의 문자를 전달할 수 있다.
이 문서는 URI 구문을 훨씬 더 넓은 문자 레퍼토리로 확장하여
Internationalized Resource Identifier (IRI)라는 새로운 프로토콜
요소를 정의한다. 또한 URI 참조와 같이 [RFC3986]의 다른
구성과 대응되는 "internationalized" 버전도 정의한다. IRI의
구문은 section 2에, IRI와 URI의 관계는 section 3에
정의되어 있다.
IRI에서 A - Z 바깥의 문자를 사용하는 것은 몇 가지 어려움을
가져온다. Section 4는 양방향 IRI의 특수한 경우를 논의하고,
section 5는 IRI 사이의 여러 동등성 형태를, section 6은
다양한 상황에서의 IRI 사용을 논의한다. Section 7은 추가적인
정보 제공 지침을, section 8은 보안 고려 사항을 제공한다.
1.2. 적용 가능성
IRI는 새로운 URI 스킴을 위한 권고 [RFC2718]와 호환되도록
설계되었다. 호환성은 IRI 문자 시퀀스에서 기능적으로 동등한
URI 문자 시퀀스로의 잘 정의되고 결정적인 매핑을 지정함으로써
제공된다. URI(또는 URI 참조) 대신 IRI(또는 IRI 참조)를 실제로
사용하는 것은 다음 조건들이 충족되는지에 달려 있다.
Duerst & Suignard Standards Track [Page 3]
RFC 3987 Internationalized Resource Identifiers January 2005
a. 프로토콜 또는 형식 요소는 IRI를 전달할 수 있다고 명시적으로
지정되어야 한다. 의도는 IRI를 받아들이도록 정의되지 않은
문맥에 IRI를 도입하는 것이 아니다. 예를 들어 XML schema
[XMLSchema]에는 IRI와 IRI 참조를 포함하는 명시적 타입
"anyURI"가 있다. 따라서 IRI와 IRI 참조는 "anyURI" 타입의
속성과 요소 안에 있을 수 있다. 반면 HTTP 프로토콜
[RFC2616]에서는 Request URI가 URI로 정의되어 있으므로,
HTTP 요청에서 IRI를 직접 사용하는 것은 허용되지 않는다.
b. IRI를 전달하는 프로토콜 또는 형식은 IRI에서 사용되는 넓은
범위의 문자를 표현할 수 있는 메커니즘을 가져야 한다.
그것은 네이티브 방식일 수도 있고, 어떤 프로토콜 또는
형식별 이스케이프 메커니즘일 수도 있다(예: [XML1]의
숫자 문자 참조).
c. 해당 IRI에 대응하는 URI는 원래 문자를 UTF-8을 사용하여
옥텟으로 인코딩해야 한다. 새로운 URI 스킴의 경우 이는
[RFC2718]에서 권장된다. 이는 전체 스킴(예: IMAP URL
[RFC2192] 및 POP URL [RFC2384], 또는 URN 구문
[RFC2141])에 적용될 수 있다. 또한 프래그먼트 식별자와
같은 URI의 특정 부분(예: [XPointer])에 적용될 수도 있다.
특정 URI 또는 그 일부에 적용될 수도 있다. 자세한 내용은
section 6.4를 참조하기 바란다.
1.3. 정의
이 문서에서는 다음 정의가 사용된다. 이들은 [RFC2130],
[RFC2277] 및 [ISO10646]의 용어를 따른다.
character: 데이터의 조직, 제어 또는 표현에 사용되는 요소
집합의 구성원. 예를 들어 "LATIN CAPITAL LETTER A"는
하나의 문자의 이름이다.
octet: 하나의 단위로 간주되는 8비트의 순서 있는 시퀀스.
character repertoire: (수학적 의미에서) 문자들의 집합.
sequence of characters: 문자들의 시퀀스(하나씩 이어지는 것).
sequence of octets: 옥텟들의 시퀀스(하나씩 이어지는 것).
character encoding: 문자 시퀀스를 옥텟 시퀀스로 표현하는 방법
(변형을 포함할 수 있음). 또한 옥텟 시퀀스를 문자 시퀀스로
(모호성 없이) 변환하는 방법.
Duerst & Suignard Standards Track [Page 4]
RFC 3987 Internationalized Resource Identifiers January 2005
charset: 문자 인코딩을 식별하는 데 사용되는 매개변수 또는
속성의 이름.
UCS: Universal Character Set. ISO/IEC 10646 [ISO10646] 및
Unicode Standard [UNIV4]에 의해 정의된 부호화 문자 집합.
IRI reference: Internationalized Resource Identifier의 일반적인
사용을 나타낸다. IRI reference는 절대적일 수도 있고 상대적일
수도 있다. 그러나 그러한 참조에서 나온 "IRI"는 절대 IRI만
포함한다. 모든 상대 IRI 참조는 절대 형식으로 해석된다.
[RFC2396]에서는 URI가 프래그먼트 식별자를 포함하지 않았지만,
[RFC3986]에서는 프래그먼트 식별자가 URI의 일부라는 점에
유의하라.
running text: 자연어의 정서법 관습에 따른 구문을 가진 인간
텍스트(단락, 문장, 구). 이는 기계 처리를 쉽게 하기 위해
정의된 구문(예: 마크업, 프로그래밍 언어)과 대비된다.
protocol element: 해당 프로토콜이 메시지를 처리하는 방식에
영향을 미치는 메시지의 모든 부분.
presentation element: 프로토콜 요소에 대응하는 표시 형식.
예를 들어 더 넓은 범위의 문자를 사용하는 것.
create (a URI or IRI): URI와 IRI와 관련하여 이 용어는 초기 생성을
의미한다. 이는 특정 식별자를 가진 리소스의 최초 생성일 수도
있고, 특정 식별자 아래에서 리소스를 처음 노출하는 것일 수도
있다.
generate (a URI or IRI): URI와 IRI와 관련하여 이 용어는 다른
정보에서 파생되어 IRI가 생성되는 경우에 사용된다.
1.4. 표기법
현재 RFC와 Internet Draft는 US-ASCII 레퍼토리 밖의 어떤 문자도
허용하지 않는다. 따라서 이 문서는 예시에서 그러한 문자를
나타내기 위해 여러 특수 표기법을 사용한다.
본문에서는 US-ASCII 밖의 문자가 때때로 접두사 'U+' 뒤에 네 개
에서 여섯 개의 16진 숫자를 붙이는 방식으로 참조된다.
예시에서 US-ASCII 밖의 문자를 표현하기 위해 이 문서는 두 가지
표기법인 'XML Notation'과 'Bidi Notation'을 사용한다.
Duerst & Suignard Standards Track [Page 5]
RFC 3987 Internationalized Resource Identifiers January 2005
XML Notation은 앞에 '&#x'를, 뒤에 ';'를 사용하고 그 사이에
UCS에서 해당 문자의 16진수를 넣는다. 예를 들어 я는
CYRILLIC CAPITAL LETTER YA를 나타낸다. 이 표기법에서 실제
'&'는 '&'로 표시된다.
Bidi Notation은 양방향 예시에 사용된다. 소문자는 왼쪽에서
오른쪽으로 쓰이는 라틴 문자나 기타 문자를 나타내며, 대문자는
오른쪽에서 왼쪽으로 쓰이는 아랍 문자나 히브리 문자를 나타낸다.
예시에서 실제 옥텟(퍼센트 인코딩된 옥텟이 아닌 것)을 나타내기
위해 옥텟을 나타내는 두 16진 숫자는 "<"와 ">"로 둘러싸인다.
예를 들어 흔히 0xc9로 표시되는 옥텟은 여기서 <c9>로 표시된다.
이 문서에서 핵심어 "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
그리고 "OPTIONAL"은 [RFC2119]에 설명된 대로 해석되어야 한다.
2. IRI 구문
이 절은 Internationalized Resource Identifiers (IRIs)의 구문을
정의한다.
URI와 마찬가지로 IRI는 옥텟 시퀀스가 아니라 문자 시퀀스로
정의된다. 이 정의는 IRI가 디지털 방식으로 저장되거나 전송될
뿐만 아니라 종이에 쓰이거나 라디오를 통해 읽힐 수도 있다는
사실을 수용한다. 동일한 IRI는, 서로 다른 프로토콜이나 문서가
서로 다른 문자 인코딩(및/또는 전송 인코딩)을 사용하는 경우,
서로 다른 옥텟 시퀀스로 표현될 수 있다. 포함하는 프로토콜이나
문서와 동일한 문자 인코딩을 사용하면 IRI 안의 문자가 프로토콜
또는 문서의 나머지 부분과 같은 방식으로 처리될 수 있다
(예: 검색, 변환, 표시).
2.1. IRI 구문 요약
IRI는 [RFC3986]의 URI와 유사하게 정의되지만, 비예약 문자
클래스는 아래 구문 규칙과 section 6.1에 제시된 제한을 조건으로,
U+007F를 넘어서는 UCS(Universal Character Set, [ISO10646])
문자를 추가함으로써 확장된다.
그 외에는 구성 요소와 예약 문자의 구문 및 사용은 [RFC3986]의
것과 동일하다. 상대 참조의 해석과 같이 [RFC3986]에 정의된
모든 연산은 IRI 처리 소프트웨어에 의해 URI 처리 소프트웨어가
URI에 적용하는 것과 정확히 같은 방식으로 IRI에 적용될 수 있다.
Duerst & Suignard Standards Track [Page 6]
RFC 3987 Internationalized Resource Identifiers January 2005
US-ASCII 레퍼토리 밖의 문자는 예약되어 있지 않으므로 새로
정의되는 스킴에서 구성 요소를 구분하는 것과 같은 구문 목적에
사용되어서는 안 된다(MUST NOT). 예를 들어 U+00A2, CENT SIGN은
'iunreserved' 범주에 있으므로 IRI에서 구분자로 허용되지 않는다.
이는 '-'가 'unreserved' 범주에 있기 때문에 URI에서 구분자로
사용할 수 없는 사실과 유사하다.
2.2. IRI 참조와 IRI를 위한 ABNF
IRI 참조와 IRI를 단순히 URI 참조와 URI로의 변환을 통해 정의할
수도 있겠지만, 이들은 직접 수용되고 처리될 수도 있다. 따라서
IRI 참조(가장 일반적인 개념이며 문법의 시작점)와 IRI에 대한
ABNF 정의가 여기에 제시된다. 이 ABNF의 구문은 [RFC2234]에
설명되어 있다. 문자 번호는 실제 이진 인코딩을 암시하지 않고
UCS에서 가져온다. ABNF의 터미널은 바이트가 아니라 문자이다.
다음 문법은 [RFC3986]의 URI 문법을 밀접하게 따른다. 다만
비예약 문자의 범위가 UCS 문자를 포함하도록 확장되었으며,
private UCS 문자는 query 부분에서만 나타날 수 있다는 제한이
있다. 문법은 두 부분으로 나뉜다. 위에서 언급한 확장 때문에
[RFC3986]과 다른 규칙, 그리고 [RFC3986]의 규칙과 동일한
규칙이다. [RFC3986]의 규칙과 다른 규칙의 경우 비단말 이름은
다음과 같이 변경되었다. 비단말이 'URI'를 포함하면 이를 'IRI'로
바꾸었다. 그렇지 않으면 앞에 'i'를 붙였다.
다음 규칙들은 [RFC3986]의 규칙과 다르다.
IRI = scheme ":" ihier-part [ "?" iquery ]
[ "#" ifragment ]
ihier-part = "//" iauthority ipath-abempty
/ ipath-absolute
/ ipath-rootless
/ ipath-empty
IRI-reference = IRI / irelative-ref
absolute-IRI = scheme ":" ihier-part [ "?" iquery ]
irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ]
irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute
Duerst & Suignard Standards Track [Page 7]
RFC 3987 Internationalized Resource Identifiers January 2005
/ ipath-noscheme
/ ipath-empty
iauthority = [ iuserinfo "@" ] ihost [ ":" port ]
iuserinfo = *( iunreserved / pct-encoded / sub-delims / ":" )
ihost = IP-literal / IPv4address / ireg-name
ireg-name = *( iunreserved / pct-encoded / sub-delims )
ipath = ipath-abempty ; begins with "/" or is empty
/ ipath-absolute ; begins with "/" but not "//"
/ ipath-noscheme ; begins with a non-colon segment
/ ipath-rootless ; begins with a segment
/ ipath-empty ; zero characters
ipath-abempty = *( "/" isegment )
ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]
ipath-noscheme = isegment-nz-nc *( "/" isegment )
ipath-rootless = isegment-nz *( "/" isegment )
ipath-empty = 0<ipchar>
isegment = *ipchar
isegment-nz = 1*ipchar
isegment-nz-nc = 1*( iunreserved / pct-encoded / sub-delims
/ "@" )
; non-zero-length segment without any colon ":"
ipchar = iunreserved / pct-encoded / sub-delims / ":"
/ "@"
iquery = *( ipchar / iprivate / "/" / "?" )
ifragment = *( ipchar / "/" / "?" )
iunreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar
ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD
iprivate = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD
일부 생성 규칙은 모호하다. "first-match-wins" (일명
"greedy") 알고리즘이 적용된다. 자세한 내용은 [RFC3986]을
참조하라.
Duerst & Suignard Standards Track [Page 8]
RFC 3987 Internationalized Resource Identifiers January 2005
다음 규칙들은 [RFC3986]의 규칙과 동일하다.
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
port = *DIGIT
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
이 구문은 IPv6 scoped addressing zone identifier를 지원하지 않는다.
Duerst & Suignard Standards Track [Page 9]
RFC 3987 Internationalized Resource Identifiers January 2005
3. IRI와 URI의 관계
IRI는 UCS 기반 문자 레퍼토리를 사용하는 프로토콜, 형식 및
소프트웨어 구성 요소에서 리소스를 식별할 때 URI를 대체하기
위한 것이다. 이러한 프로토콜과 구성 요소는 리소스 식별자가
단순히 식별 목적으로 사용되는 경우 특히 URI를 직접 사용할
필요가 전혀 없을 수도 있다. 그러나 리소스 식별자가 리소스
검색에 사용되는 경우에는 현재 대부분의 검색 메커니즘이 URI에
대해서만 정의되어 있으므로, 많은 경우 연관된 URI를 결정해야
한다. 이 경우 IRI는 URI 프로토콜 요소를 위한 표시 요소로
기능할 수 있다. 예로 Web user agent의 주소 표시줄을 들 수
있다. (추가적인 근거는 section 3.1에 제시되어 있다.)
3.1. IRI에서 URI로의 매핑
이 절은 IRI를 URI로 매핑하는 방법을 정의한다. 이 절의 모든
내용은 IRI 참조와 URI 참조뿐 아니라 그 구성 요소(예:
프래그먼트 식별자)에도 적용된다.
이 매핑은 두 가지 목적을 가진다.
Syntaxical. 많은 URI 스킴과 구성 요소는 section 2.2에
포착되지 않은 추가적인 구문 제한을 정의한다. 스킴별 제한은
IRI를 URI로 변환하고 URI를 스킴별 제한과 대조하여 확인함으로써
IRI에 적용된다.
Interpretational. URI는 다양한 방식으로 리소스를 식별한다.
IRI도 리소스를 식별한다. IRI가 오직 식별 목적으로 사용되는
경우에는 IRI를 URI로 매핑할 필요가 없다(section 5 참조).
그러나 IRI가 리소스 검색에 사용되는 경우, IRI가 위치시키는
리소스는 여기에 정의된 절차에 따라 IRI를 변환한 뒤 얻은 URI가
위치시키는 리소스와 동일하다. 이는 IRI 수준에서 별도의 해석을
정의할 필요가 없다는 뜻이다.
애플리케이션은 다음 두 단계를 사용하여 IRI를 URI로 매핑해야
한다(MUST).
Step 1. 원래 IRI 형식에서 UCS 문자 시퀀스를 생성한다. 이
단계에는 입력 형식에 따라 다음 세 가지 변형이 있다.
a. IRI가 종이에 쓰였거나, 소리 내어 읽혔거나, 문자
인코딩과 독립적인 문자 시퀀스로 달리 표현된 경우,
IRI를 Normalization Form C (NFC, [UTR15])에 따라
정규화된 UCS 문자 시퀀스로 표현한다.
Duerst & Suignard Standards Track [Page 10]
RFC 3987 Internationalized Resource Identifiers January 2005
b. IRI가 어떤 알려진 비유니코드 문자 인코딩의 디지털
표현(예: 옥텟 스트림) 안에 있는 경우, IRI를 NFC에
따라 정규화된 UCS 문자 시퀀스로 변환한다.
c. IRI가 유니코드 기반 문자 인코딩(예: UTF-8 또는
UTF-16) 안에 있는 경우에는 정규화하지 않는다(자세한
내용은 section
5.3.2.2 참조). 인코딩된 유니코드 문자
시퀀스에 바로 step 2를 적용한다.
Step 2. 'ucschar' 또는 'iprivate'의 각 문자에 대해 아래 step
2.1부터 2.3까지를 적용한다.
2.1. UTF-8 [RFC3629]을 사용하여 문자를 하나 이상의 옥텟
시퀀스로 변환한다.
2.2. 각 옥텟을 %HH로 변환한다. 여기서 HH는 옥텟 값의 16진
표기이다. 이는 [RFC3986]의 section 2.1에 있는
퍼센트 인코딩 메커니즘과 동일하다는 점에 유의하라.
변동성을 줄이기 위해 16진 표기는 대문자를 사용하는 것이
좋다(SHOULD).
2.3. 원래 문자를 그 결과 문자 시퀀스(즉, %HH triplet의
시퀀스)로 대체한다.
위의 IRI에서 URI로의 매핑은 [RFC3986]을 완전히 준수하는 URI를
생성한다. 이 매핑은 URI에 대해서는 항등 변환이기도 하며,
멱등적이다. 매핑을 두 번째로 적용해도 아무것도 바뀌지 않는다.
모든 URI는 정의상 IRI이다.
IRI를 받아들이는 시스템은, 해당 스킴이 ireg-name에서 도메인
이름을 사용하는 것으로 알려져 있고 스킴 정의가 ireg-name에
퍼센트 인코딩을 허용하지 않는 경우, 위의 step 2 전에 IRI의
ireg-name 구성 요소를 다음과 같이 변환할 수 있다(MAY).
IRI의 ireg-name 부분을 각 점으로 구분된 라벨에 대해
[RFC3490]의 section 4.1에 지정된 ToASCII 연산을 사용하여
변환한 부분으로 바꾸고, 라벨 구분자로 U+002E (FULL STOP)을
사용한다. 이때 UseSTD3ASCIIRules 플래그는 TRUE로 설정하고,
AllowUnassigned 플래그는 IRI를 생성할 때 FALSE로, 그 밖의 경우
TRUE로 설정한다.
Duerst & Suignard Standards Track [Page 11]
RFC 3987 Internationalized Resource Identifiers January 2005
ToASCII 연산은 실패할 수 있지만, 이는 IRI를 해석할 수 없다는
의미가 된다. 이 변환은 기존 URI resolver와의 상호 운용성을
최대화하는 것이 목표일 때 사용되어야 한다(SHOULD). 예를 들어
IRI
"http://résumé.example.org"
는 다음으로 변환될 수 있다.
"http://xn--rsum-bpad.example.org"
다음 대신
"http://r%C3%A9sum%C3%A9.example.org".
ireg-name에서 도메인 이름을 사용하는 것으로 알려져 있지만 스킴
정의가 ireg-name에 퍼센트 인코딩을 허용하지 않는 스킴을 가진
IRI는, 직접 변환 또는 ireg-name에 ToASCII 연산을 사용한 변환의
결과 중 하나가 스킴별 제한을 충족하는 URI를 만들어 내는 경우,
스킴별 제한을 충족한다.
그러한 IRI는 IRI를 변환하고 ireg-name에 ToASCII 연산을 사용한
뒤 얻은 URI로 해석된다. 구현은 동일한 결과를 생성하는 한 이
변환을 반드시 수행할 필요는 없다.
Note: step 1의 variants b와 c의 차이(NFC로 정규화하는 것과,
아무 정규화도 하지 않는 것)는 많은 비유니코드 문자 인코딩에서
일부 텍스트를 직접 표현할 수 없다는 사실을 반영한다. 예를
들어 "Vietnam"이라는 단어는 NFC에서는 본래 "Việt Nam"
(LATIN SMALL LETTER E WITH CIRCUMFLEX AND DOT BELOW 포함)으로
쓰이지만, windows-1258 문자 인코딩에서 직접 트랜스코딩하면
"Việt Nam" (LATIN SMALL LETTER E WITH CIRCUMFLEX
뒤에 COMBINING DOT BELOW가 따름)이 된다. 베트남어의 다른 8비트
인코딩을 직접 트랜스코딩하면 다른 표현이 나올 수 있다.
Note: step 2에서 전체 IRI를 균일하게 처리하는 것은 처리가 URI
스킴과 독립적이 되도록 하는 데 중요하다. 자세한 논의는
[Gettys]를 참조하라.
Note: 실제로는 IRI에서 URI로의 매핑과 해석이 긴밀하게 통합되어
있는 경우(예: 같은 user agent에서 수행되는 경우), 일반 매핑
(steps 1 and 2)을 사용하는지, ireg-name에 대해 [RFC3490]의
ToASCII 연산을 사용하는지의 차이는 눈에 띄지 않을 것이다. 그러나
Duerst & Suignard Standards Track [Page 12]
RFC 3987 Internationalized Resource Identifiers January 2005
[RFC3490]을 사용한 변환은, HTTP 프록시를 사용하는 경우처럼
매핑과 해석이 분리되어 있는 경우 하위 호환성 문제를 더 잘
처리할 수 있을 수도 있다.
Note: Internationalized Domain Names는 IRI의 ireg-name 부분이 아닌
다른 부분에도 포함될 수 있다. Internationalized Domain Name이
스킴 구문의 일부인 경우에는 스킴별 구현이, 'iquery'의 일부인
경우에는 서버 측 구현이 적절한 지점에서 필요한 변환을 적용할
책임이 있다. 예: http://résumé.example.org의 Web
페이지를 검증하려고 하면
http://validator.w3.org/check?uri=http%3A%2F%2Frésumé.
example.org라는 IRI가 되며, 이는
http://validator.w3.org/check?uri=http%3A%2F%2Fr%C3%A9sum%C3%A9.
example.org라는 URI로 변환된다. Web 페이지를 가져올 수
있도록 필요한 변환을 수행하는 것은 서버 측 구현의 책임이다.
IRI를 받아들이는 시스템은 위 step 2에서 URI에서 허용되지 않는
US-ASCII의 출력 가능한 문자, 즉 "<", ">", '"', space, "{",
"}", "|", "\", "^", 그리고 "`"도 처리할 수 있다(MAY). 이러한
문자가 발견되었지만 변환되지 않는 경우, 변환은 실패해야 한다
(SHOULD). 숫자 기호("#"), 퍼센트 기호("%"), 그리고 대괄호 문자
("[", "]")는 위 목록에 포함되지 않으며 변환되어서는 안 된다
(MUST NOT). 이러한 문자를 포함하는 더 이른 IRI 정의를 사용한
프로토콜과 형식은 주어진 필드에서 실제 IRI를 추출하기 위한
전처리 단계로 이러한 문자들의 퍼센트 인코딩을 요구할 수 있다
(MAY). 이 전처리는 사용자가 IRI를 입력할 수 있게 하는
애플리케이션에서도 사용될 수 있다(MAY).
Note: 이 과정(step 2.3)에서는 URI 참조에서 허용되는 문자와
기존 퍼센트 인코딩 시퀀스가 더 이상 인코딩되지 않는다. (이
매핑은 임의의 내용을 URI의 어떤 부분에 포함할 때 적용되는
인코딩과 유사하지만 다르다.) 예를 들어 XML 표기법의 IRI
"http://www.example.org/red%09rosé#red"는
"http://www.example.org/red%09ros%C3%A9#red"로 변환되며,
다음과 같은 것으로 변환되지 않는다.
"http%3A%2F%2Fwww.example.org%2Fred%2509ros%C3%A9%23red".
Note: UTF-8로 트랜스코딩하는 일부 오래된 소프트웨어는 일부
입력, 특히 BMP(Basic Multilingual Plane) 밖의 문자에 대해
잘못된 출력을 생성할 수 있다. 예로, XML Notation으로 된
다음 비-BMP 문자를 포함하는 IRI의 경우:
"http://example.com/𐌀𐌁𐌂";
Duerst & Suignard Standards Track [Page 13]
RFC 3987 Internationalized Resource Identifiers January 2005
이는 Old Italic 알파벳의 처음 세 글자를 포함하며, URI로의
올바른 변환은 다음과 같다.
"http://example.com/%F0%90%8C%80%F0%90%8C%81%F0%90%8C%82"
3.2. URI를 IRI로 변환
어떤 상황에서는 URI를 동등한 IRI로 변환하는 것이 바람직할 수
있다. 이 절은 이 변환을 위한 절차를 제공한다. 이 절에서 설명한
변환은 항상 변환의 입력으로 사용된 URI로 다시 매핑되는 IRI를
결과로 낸다(퍼센트 인코딩의 대소문자 차이와, 퍼센트 인코딩된
비예약 문자가 있을 수 있는 경우를 제외한다). 그러나 이 변환의
결과인 IRI가 원래의 IRI(그런 것이 있었다면)와 정확히 같지는
않을 수 있다.
URI에서 IRI로의 변환은 퍼센트 인코딩을 제거하지만, 모든 퍼센트
인코딩을 제거할 수 있는 것은 아니다. 여기에는 몇 가지 이유가
있다.
1. 일부 퍼센트 인코딩은 예약 문자의 퍼센트 인코딩된 사용과
인코딩되지 않은 사용을 구별하기 위해 필요하다.
2. 일부 퍼센트 인코딩은 UTF-8 옥텟 시퀀스로 해석될 수 없다.
(Note: UTF-8의 옥텟 패턴은 매우 규칙적이다. 따라서 UTF-8
옥텟 시퀀스로 해석될 수 있는 퍼센트 인코딩은 실제로 UTF-8에서
유래했을 가능성이 매우 높지만, 보장은 없다. 자세한 논의는
[Duerst97]를 참조하라.)
3. 변환 결과 IRI에 적절하지 않은 문자가 나올 수 있다. 자세한
내용은 sections 2.2, 4.1, 그리고 6.1을 참조하라.
URI에서 IRI로의 변환은 다음 단계들(또는 동일한 결과를 생성하는
다른 알고리즘)을 사용하여 수행된다.
1. URI를 US-ASCII의 옥텟 시퀀스로 표현한다.
2. 모든 퍼센트 인코딩("%" 뒤에 두 개의 16진 숫자가 오는 것)을
해당 옥텟으로 변환한다. 다만 "%", "reserved" 안의 문자,
그리고 URI에서 허용되지 않는 US-ASCII 문자에 해당하는 것은
제외한다.
3. step 2에서 생성된 옥텟 중 엄격하게 올바른 UTF-8 옥텟
시퀀스의 일부가 아닌 모든 옥텟을 다시 퍼센트 인코딩한다.
Duerst & Suignard Standards Track [Page 14]
RFC 3987 Internationalized Resource Identifiers January 2005
4. step 3에서 생성된 옥텟 중 UTF-8에서 sections 2.2,
4.1, 그리고 6.1에 따라 적절하지 않은 문자를 나타내는
모든 옥텟을 다시 퍼센트 인코딩한다.
5. 결과 옥텟 시퀀스를 UTF-8로 인코딩된 문자 시퀀스로 해석한다.
이 절차는 가능한 한 많은 퍼센트 인코딩된 문자를 IRI의 문자로
변환한다. step 4가 적용될 때 몇 가지 선택지가 있으므로
(section 6.1 참조), 결과는 달라질 수 있다.
URI에서 IRI로의 변환은, URI에서 UTF-8 이외의 다른 문자 인코딩이
사용되었다고 문맥에서 추측할 수 있을 것 같더라도, steps 3과
4에서 UTF-8 이외의 어떤 문자 인코딩도 사용해서는 안 된다
(MUST NOT). 예를 들어 URI
"http://www.example.org/r%E9sum%E9.html"은 약간의 추측으로
iso-8859-1로 인코딩된 두 개의 e-acute 문자를 포함하는 것으로
해석될 수도 있다. 이것을 이러한 e-acute 문자를 포함하는 IRI로
변환해서는 안 된다. 그렇지 않으면 미래에 그 IRI는
"http://www.example.org/r%C3%A9sum%C3%A9.html"로 매핑될 것이며,
이는 "http://www.example.org/r%E9sum%E9.html"과 다른 URI이다.
3.2.1. 예시
이 절은 URI를 IRI로 변환하는 여러 예시를 보여준다. 각 예시는
steps 1부터 5까지가 적용된 뒤의 결과를 보여준다. 최종 결과에는
XML Notation이 사용된다. 옥텟은 "<" 뒤에 두 개의 16진 숫자가
오고 그 뒤에 ">"가 오는 방식으로 표시된다.
다음 예시는 엄격하게 올바른 UTF-8 시퀀스이며 실제 문자 U+00FC,
LATIN SMALL LETTER U WITH DIAERESIS(u-umlaut라고도 함)로 변환되는
시퀀스 "%C3%BC"를 포함한다.
1. http://www.example.org/D%C3%BCrst
2. http://www.example.org/D<c3><bc>rst
3. http://www.example.org/D<c3><bc>rst
4. http://www.example.org/D<c3><bc>rst
5. http://www.example.org/Dürst
다음 예시는 iso-8859-1 문자 인코딩에서 U+00FC, LATIN SMALL
LETTER U WITH DIAERESIS를 나타낼 수도 있는 시퀀스 "%FC"를
포함한다. (다른 문자 인코딩에서는 다른 문자를 나타낼 수도
있다. 예를 들어 iso-8859-5에서 옥텟 <fc>는
Duerst & Suignard Standards Track [Page 15]
RFC 3987 Internationalized Resource Identifiers January 2005
U+045C, CYRILLIC SMALL LETTER KJE를 나타낸다.) <fc>는 엄격하게
올바른 UTF-8 시퀀스의 일부가 아니므로, step 3에서 다시
퍼센트 인코딩된다.
1. http://www.example.org/D%FCrst
2. http://www.example.org/D<fc>rst
3. http://www.example.org/D%FCrst
4. http://www.example.org/D%FCrst
5. http://www.example.org/D%FCrst
다음 예시는 U+202E, RIGHT-TO-LEFT OVERRIDE의 퍼센트 인코딩된
UTF-8 문자 인코딩인 "%e2%80%ae"를 포함한다.
Section 4.1은 이 문자를 IRI에서 직접 사용하는 것을 금지한다.
따라서 해당 옥텟은 step 4에서 다시 퍼센트 인코딩된다. 이 예시는
퍼센트 인코딩에 사용된 글자의 대소문자가 보존되지 않을 수 있음을
보여준다. 이 예시는 punycode로 인코딩된 도메인 이름 라벨
(xn--99zt52a)도 포함하며, 이는 변환되지 않는다.
1. http://xn--99zt52a.example.org/%e2%80%ae
2. http://xn--99zt52a.example.org/<e2><80><ae>
3. http://xn--99zt52a.example.org/<e2><80><ae>
4. http://xn--99zt52a.example.org/%E2%80%AE
5. http://xn--99zt52a.example.org/%E2%80%AE
스킴별 지식을 가진 구현은 ToUnicode 절차를 사용하여 punycode로
인코딩된 도메인 이름 라벨을 해당 문자로 변환할 수 있다(MAY).
따라서 위 예시의 경우 라벨 "xn--99zt52a"는 U+7D0D U+8C46
(Japanese Natto)로 변환될 수 있으며, 전체 IRI는
"http://納豆.example.org/%E2%80%AE"가 된다.
4. 오른쪽에서 왼쪽으로 쓰는 언어를 위한 양방향 IRI
아랍 문자와 히브리 문자에서 사용되는 것과 같은 일부 UCS 문자는
본질적으로 오른쪽에서 왼쪽(rtl)으로 쓰는 방향을 가진다. 이러한
문자를 포함하는 IRI(양방향 IRI 또는 Bidi IRI라 함)는 논리적
표현(디지털 표현과 읽기/철자에 사용됨)과 시각적 표현(표시/인쇄에
사용됨) 사이의 단순하지 않은 관계 때문에 추가적인 주의가 필요하다.
Duerst & Suignard Standards Track [Page 16]
RFC 3987 Internationalized Resource Identifiers January 2005
Bidi IRI의 논리적 표현, 시각적 표현, 그리고 구문 사이의 복잡한
상호작용 때문에, 여러 요구 사항 사이의 균형이 필요하다. 주요
요구 사항은 다음과 같다.
1. 시각적 표현과 논리적 표현 사이에서 사용자가 예측할 수 있는
변환;
2. IRI의 여러 부분에 넓은 범위의 문자를 포함할 수 있는 능력;
그리고
3. 구현에 대한 변경이나 제한이 적거나 없음.
4.1. 논리적 저장과 시각적 표현
디지털 표현으로 저장되거나 전송될 때, 양방향 IRI는 반드시
완전한 논리적 순서여야 하며 IRI 구문 규칙(해당 스킴과 관련된
규칙 포함)을 준수해야 한다(MUST). 이는 양방향 IRI가 다른 IRI와
같은 방식으로 처리될 수 있도록 보장한다.
양방향 IRI는 Unicode Bidirectional Algorithm [UNIV4], [UNI9]을
사용하여 렌더링되어야 한다(MUST). 양방향 IRI는 왼쪽에서
오른쪽 임베딩 안에 있는 것처럼, 즉 앞에 U+202A,
LEFT-TO-RIGHT EMBEDDING (LRE)가 있고 뒤에 U+202C, POP
DIRECTIONAL FORMATTING (PDF)가 있는 것처럼 렌더링되어야 한다
(MUST). 임베딩 방향 설정은 상위 수준 프로토콜(예: HTML의
dir='ltr' 속성)에서도 수행할 수 있다.
임베딩이 없어도 표시가 여전히 같다면 위 임베딩을 사용할 필요는
없다. 예를 들어, 영어나 키릴 문자에 사용되는 것과 같은
왼쪽에서 오른쪽 기본 방향성의 텍스트 안에 있는 양방향 IRI가
공백과 강한 왼쪽에서 오른쪽 문자 앞뒤에 놓인 경우에는 임베딩이
필요하지 않다. 또한, 강한 오른쪽에서 왼쪽 문자와 약한 문자만
포함하고 강한 오른쪽에서 왼쪽 문자로 시작하고 끝나는 양방향
상대 IRI 참조가, 아랍어나 히브리어에 사용되는 것과 같은
오른쪽에서 왼쪽 기본 방향성의 텍스트 안에 나타나며 공백과 강한
문자 앞뒤에 놓인 경우에도 임베딩이 필요하지 않다.
Duerst & Suignard Standards Track [Page 17]
RFC 3987 Internationalized Resource Identifiers January 2005
그 밖의 일부 경우에는 U+200E, LEFT-TO-RIGHT MARK (LRM)를
사용하는 것만으로도 올바른 표시 동작을 강제하기에 충분할 수
있다. 그러나 Unicode Bidirectional algorithm의 세부 사항은 항상
이해하기 쉬운 것은 아니다. 구현자는 임베딩이 없어도 표시 동작에
영향이 없다고 완전히 확신하지 못하는 모든 경우에는 주의하는
쪽으로 판단하여 임베딩을 사용할 것을 강력히 권고받는다.
Unicode Bidirectional Algorithm([UNI9], section 4.3)은 상위 수준
프로토콜이 양방향 렌더링에 영향을 줄 수 있도록 허용한다. 이러한
상위 수준 프로토콜의 변경은 IRI의 렌더링을 바꾸는 경우 사용해서는
안 된다(MUST NOT).
올바른 표시를 보장하기 위해 IRI 앞이나 뒤에 사용될 수 있는
양방향 서식 문자는 그 자체로 IRI의 일부가 아니다. IRI는 양방향
서식 문자(LRM, RLM, LRE, RLE, LRO, RLO, 그리고 PDF)를 포함해서는
안 된다(MUST NOT). 이들은 IRI의 시각적 렌더링에 영향을 주지만
스스로 나타나지는 않는다. 따라서 그러한 문자를 포함하는 IRI를
올바르게 입력하는 것은 불가능하다.
4.2. Bidi IRI 구조
Unicode Bidirectional Algorithm은 주로 running text를 위해
설계되었다. 그것이 양방향 IRI의 렌더링에 너무 큰 영향을 주지
않도록 하기 위해, 양방향 IRI에 대한 몇 가지 제한이 필요하다.
이러한 제한은 구분자(구조 문자, 주로 "@", ".", ":", "/"와 같은
문장 부호)와 구성 요소(보통 대부분 글자와 숫자로 이루어짐)의
관점에서 제시된다.
section 2.2의 다음 구문 규칙들은 Bidi 동작의 목적상 구성 요소에
해당한다: iuserinfo, ireg-name, isegment, isegment-nz,
isegment-nz-nc, ireg-name, iquery, 그리고 ifragment.
위 구성 요소 중 어느 하나의 구문을 정의하는 명세는 이를 더
세분화하고, 이 문서에 따라 더 작은 부분들을 구성 요소로 정의할
수 있다(MAY). 예를 들어, [RFC3490]의 양방향 도메인 이름에
대한 제한은 ireg-name을 도메인 이름으로 사용하는 스킴에서 도메인
이름의 각 라벨을 구성 요소로 취급하는 것에 해당한다. 구성 요소가
공식적으로 정의되지 않은 경우에도, 어떤 구문을 구성 요소의
관점에서 생각하고 관련 제한을 적용하는 것이 도움이 될 수 있다.
예를 들어 query 부분의 일반적인 name/value 구문에서는 각 name과
각 value를 구성 요소로 취급하는 것이 편리하다. 또 다른 예로,
리소스 이름의 확장자를 별도의 구성 요소로 취급할 수 있다.
Duerst & Suignard Standards Track [Page 18]
RFC 3987 Internationalized Resource Identifiers January 2005
각 구성 요소에 대해 다음 제한이 적용된다.
1. 구성 요소는 오른쪽에서 왼쪽 문자와 왼쪽에서 오른쪽 문자를
둘 다 사용하지 않는 것이 좋다(SHOULD NOT).
2. 오른쪽에서 왼쪽 문자를 사용하는 구성 요소는 오른쪽에서 왼쪽
문자로 시작하고 끝나는 것이 좋다(SHOULD).
위 제한들은 must가 아니라 should로 제시되어 있다. 시각적으로
표시되지 않는 IRI의 경우에는 관련이 없다. 그러나 일반적인 IRI의
경우, 양방향에서 시각적 표현과 논리적 표현 사이의 일관된 변환을
보장하는 데 매우 중요하다.
Note: 일부 구성 요소에서는 위 제한이 실제로 엄격하게 강제될 수
있다. 예를 들어 [RFC3490]은 ireg-name이 호스트 이름인 스킴에
대해 이러한 제한이 호스트 이름의 라벨에 적용될 것을 요구한다.
다른 일부 구성 요소(예: path 구성 요소)에서는 이러한 제한을
따르는 것이 그리 어렵지 않을 수 있다. query 부분의 일부와
같은 다른 구성 요소에서는 query 매개변수의 값이 임의의 문자
시퀀스일 수 있기 때문에 제한을 강제하기가 매우 어려울 수 있다.
위 제한을 다른 방식으로 충족할 수 없다면, 영향을 받는 구성
요소는 언제나 section 3.1에 설명된 대로 URI 표기법으로 매핑될 수
있다. 전체 구성 요소가 매핑되어야 한다는 점에 유의하라(아래
Example 9도 참조).
4.3. Bidi IRI 입력
Bidi 입력 방법은 Bidi IRI를 논리적 순서로 생성하면서
section 4.1에 따라 렌더링해야 한다(MUST). 입력 중에는 최종
사용자 혼란을 피하기 위해 새 문자가 입력될 때마다 렌더링을
갱신하는 것이 좋다(SHOULD).
4.4. 예시
이 절은 Bidi Notation으로 된 양방향 IRI의 예시를 제공한다.
논리적 표현과 시각적 표현 사이의 관계를 가진 유효한 IRI를
보여주고, 이 관계에서 특정 현상이 양방향 동작에 익숙하지 않은
사람에게는 이상하게 보일 수 있지만 아랍어와 히브리어 사용자에게는
익숙할 수 있음을 설명한다. 또한 section 4.2에 제시된 제한을
따르지 않으면 어떤 일이 일어나는지도 보여준다. 아래 예시는
[BidiEx]에서 아랍어, 히브리어, Bidi Notation 변형으로 볼 수
있다.
Duerst & Suignard Standards Track [Page 19]
RFC 3987 Internationalized Resource Identifiers January 2005
예시의 bidi 텍스트를 읽으려면, rtl 텍스트 블록을 만날 때까지
시각적 표현을 왼쪽에서 오른쪽으로 읽는다. rtl 블록(슬래시와
기타 특수 문자 포함)은 오른쪽에서 왼쪽으로 읽고, 그 다음 아직
읽지 않은 ltr 문자에서 계속한다.
Example 1: rtl 문자를 가진 단일 구성 요소가 반전된다:
Logical representation: "http://ab.CDEFGH.ij/kl/mn/op.html"
Visual representation: "http://ab.HGFEDC.ij/kl/mn/op.html"
구성 요소는 하나씩 읽을 수 있으며, 각 구성 요소는 자신의 자연
방향으로 읽을 수 있다.
Example 2: rtl 문자를 가진 연속된 둘 이상의 구성 요소는 전체가
반전된다:
Logical representation: "http://ab.CDE.FGH/ij/kl/mn/op.html"
Visual representation: "http://ab.HGF.EDC/ij/kl/mn/op.html"
rtl 구성 요소의 시퀀스는 bidi 텍스트에서 rtl 단어들의 시퀀스를
rtl로 읽는 것과 같은 방식으로 rtl로 읽는다.
Example 3: IRI의 모든 구성 요소(스킴 제외)가 rtl이다.
모든 rtl 구성 요소는 전체적으로 반전된다:
Logical representation: "http://AB.CD.EF/GH/IJ/KL?MN=OP;QR=ST#UV"
Visual representation: "http://VU#TS=RQ;PO=NM?LK/JI/HG/FE.DC.BA"
전체 IRI(스킴 제외)는 rtl로 읽는다. rtl 구성 요소 사이의 구분자는
각 구성 요소 사이에 머문다. ltr 구성 요소와 rtl 구성 요소 사이의
구분자는 이동하지 않는다.
Example 4: 여러 rtl 구성 요소 시퀀스 각각은 독립적으로 반전된다:
Logical representation: "http://AB.CD.ef/gh/IJ/KL.html"
Visual representation: "http://DC.BA.ef/gh/LK/JI.html"
rtl 구성 요소의 각 시퀀스는 ltr 텍스트 안의 rtl 단어 시퀀스를
rtl로 읽는 것과 같은 방식으로 rtl로 읽는다.
Example 5: Example 2를 서로 다른 종류의 구성 요소에 적용:
Logical representation: "http://ab.cd.EF/GH/ij/kl.html"
Visual representation: "http://ab.cd.HG/FE/ij/kl.html"
도메인 이름 라벨과 path 구성 요소의 반전은 예상 밖일 수 있지만,
다른 bidi 동작과 일관된다. 도메인 구성 요소가 정말로 "ab.cd.EF"임을
확인하려면 bidi 알고리즘에 따라 시각적 표현을 소리 내어 읽는 것이
도움이 될 수 있다. "http://ab.cd." 뒤에는 RTL 블록
"E-F-slash-G-H"를 읽게 되며, 이는 논리적 표현에 대응한다.
Example 6: Example 5와 같지만 더 많은 rtl 구성 요소를 가짐:
Logical representation: "http://ab.CD.EF/GH/IJ/kl.html"
Visual representation: "http://ab.JI/HG/FE.DC/kl.html"
구분자도 함께 이동하기 때문에 도메인 이름 라벨과 path 구성 요소의
반전을 더 쉽게 식별할 수 있다.
Duerst & Suignard Standards Track [Page 20]
RFC 3987 Internationalized Resource Identifiers January 2005
Example 7: 단일 rtl 구성 요소가 숫자를 포함한다:
Logical representation: "http://ab.CDE123FGH.ij/kl/mn/op.html"
Visual representation: "http://ab.HGF123EDC.ij/kl/mn/op.html"
숫자는 모든 경우 ltr로 쓰이지만 rtl 문자 run 안의 추가 임베딩으로
처리된다. 이는 일반적인 양방향 텍스트와 완전히 일관된다.
Example 8 (허용되지 않음): 숫자가 rtl 구성 요소의 시작 또는 끝에
있다:
Logical representation: "http://ab.cd.ef/GH1/2IJ/KL.html"
Visual representation: "http://ab.cd.ef/LK/JI1/2HG.html"
시퀀스 "1/2"는 bidi 알고리즘에 의해 분수로 해석되어 구성 요소를
쪼개고 혼란을 초래한다. 숫자에 가깝게 특수한 방식으로 해석되는
다른 문자들도 있다. 특히 "+", "-", "#", "$", "%", ",", ".",
그리고 ":"가 그렇다.
Example 9 (허용되지 않음): 이전 예시의 숫자가 퍼센트 인코딩되어
있다:
Logical representation: "http://ab.cd.ef/GH%31/%32IJ/KL.html",
Visual representation (Hebrew): "http://ab.cd.ef/%31HG/LK/JI%32.html"
Visual representation (Arabic): "http://ab.cd.ef/31%HG/%LK/JI32.html"
대문자가 아랍 문자를 나타내는지 히브리 문자를 나타내는지에 따라
시각적 표현이 달라진다.
Example 10 (허용되지만 권장되지 않음):
Logical representation: "http://ab.CDEFGH.123/kl/mn/op.html"
Visual representation: "http://ab.123.HGFEDC/kl/mn/op.html"
숫자로만 이루어진 구성 요소는 허용된다(이를 금지하기는 꽤
어려울 것이다). 그러나 이는 인접한 RTL 구성 요소와 예측하기 쉽지
않은 방식으로 상호작용할 수 있다.
5. 정규화와 비교
Note: 이 절의 구조와 자료 대부분은 [RFC3986]의 section 6에서
가져온 것이며, 차이는 IRI의 특수성 때문이다.
IRI에서 가장 흔한 작업 중 하나는 단순 비교이다. 이는 IRI 또는
매핑된 URI를 사용하여 각각의 리소스에 접근하지 않고 두 IRI가
동등한지를 판단하는 것이다. 비교는 응답 캐시에 접근할 때,
브라우저가 링크 색상을 지정하기 위해 히스토리를 확인할 때, 또는
XML 파서가 namespace 안의 태그를 처리할 때마다 수행된다. IRI를
비교하기 전에 광범위한 정규화를 수행하는 것은 spiders와 indexing
engines가 검색 공간을 줄이거나 요청 작업과 응답 저장의 중복을
줄이는 데 사용할 수 있다.
Duerst & Suignard Standards Track [Page 21]
RFC 3987 Internationalized Resource Identifiers January 2005
IRI 비교는 어떤 특정 목적을 위해 수행된다. 서로 다른 목적으로
IRI를 비교하는 프로토콜 또는 구현은 aliased identifiers를 줄이는
데 얼마나 많은 노력을 들일지와 관련해 서로 다른 설계 절충의
영향을 받는 경우가 많다. 이 절은 IRI를 비교하는 데 사용할 수
있는 다양한 방법, 그 사이의 절충, 그리고 이를 사용할 수 있는
애플리케이션 유형을 설명한다.
5.1. 동등성
IRI는 리소스를 식별하기 위해 존재하므로, 아마도 같은 리소스를
식별할 때 동등한 것으로 간주되어야 할 것이다. 그러나 이러한
동등성 정의는 구현이 두 리소스에 대한 완전한 지식이나 제어권을
가지지 않는 한 두 리소스를 비교할 방법이 없으므로 실용성이 크지
않다. 이 때문에 IRI의 동등성 또는 차이의 판단은 문자열 비교에
기반하며, URI 스킴 정의가 제공하는 추가 규칙 참조로 보강될 수도
있다. 우리는 그러한 비교의 가능한 결과를 설명하기 위해
"different"와 "equivalent"라는 용어를 사용하지만, 애플리케이션에
따라 동등성에는 여러 버전이 있다.
두 IRI가 동등하다고 판단할 수 있더라도, IRI 비교만으로 두 IRI가
서로 다른 리소스를 식별하는지 판단하기에는 충분하지 않다. 예를
들어 서로 다른 두 도메인 이름의 소유자가 두 도메인 모두에서 같은
리소스를 제공하기로 결정할 수 있으며, 그 결과 두 개의 서로 다른
IRI가 생긴다. 따라서 비교 방법은 false positives를 엄격히
피하면서 false negatives를 최소화하도록 설계된다.
동등성을 검사할 때 애플리케이션은 상대 참조를 직접 비교해서는
안 된다. 참조는 비교 전에 각각의 target IRI로 변환되어야 한다.
표현을 가져오는 것과 같은 네트워크 작업을 선택(또는 회피)하기
위해 IRI를 비교하는 경우, fragment 구성 요소(있는 경우)는 비교에서
제외하는 것이 좋다.
프로토콜과 아무 관계가 없는 identity tokens로 IRI를 사용하는
애플리케이션은 Simple String Comparison(section 5.3.1 참조)을
사용해야 한다(MUST). 그 밖의 모든 애플리케이션은 Comparison
Ladder(section 5.3 참조)의 비교 관행 중 하나를 선택하거나,
IRI에서 URI로 변환한 뒤 [RFC3986], section 6.2의 URI comparison
ladder에서 비교 관행 중 하나를 선택해야 한다(MUST).
5.2. 비교 준비
어떤 종류의 IRI 비교든 IRI를 전달하는 프로토콜 또는 형식 안의
모든 이스케이프나 인코딩이 해석되어 있어야 한다(REQUIRES). 이는
보통 프로토콜이나 형식이 파싱될 때 수행된다. 그러한
Duerst & Suignard Standards Track [Page 22]
RFC 3987 Internationalized Resource Identifiers January 2005
이러한 escaping 또는 encoding의 예로는 [HTML4]와 [XML1]의
entity와 numeric character reference가 있다. 예를 들어
"http://example.org/rosé" (HTML에서),
"http://example.org/rosé"; (HTML 또는 XML에서), 그리고
"http://example.org/rosé"; (HTML 또는 XML에서)는 모두
이 문서에서(section 1.4 참조) "http://example.org/rosé";
로 표시되는 것으로 해석된다(여기서 "é"는 실제 e-acute
문자를 나타내며, 이 문서가 비ASCII 문자를 포함할 수 없다는
사실을 보완하기 위한 것이다).
HTTP의 Transfer Codings([RFC2616] 참조)와 MIME의 Content
Transfer Encodings([RFC2045]) 같은 인코딩에도 유사한 고려 사항이
적용된다. 다만 이러한 경우 인코딩은 문자가 아니라 옥텟을
기반으로 하며, 임의의 옥텟만이 아니라 문자를 비교하도록 보장하기
위해 추가적인 주의가 필요하다(section 5.3.1 참조).
5.3. 비교 사다리
실제로는 IRI 동등성을 검사하기 위해 다양한 방법이 사용된다.
이러한 방법들은 필요한 처리량과 false negatives 가능성을 줄이는
정도에 따라 구분되는 범위에 속한다. 위에서 언급했듯이 false
negatives는 제거될 수 없다. 실제로 그 가능성은 줄일 수 있지만,
이를 줄이려면 더 많은 처리가 필요하며 모든 애플리케이션에 대해
비용 효율적인 것은 아니다.
이러한 비교 관행의 범위를 사다리로 본다면, 다음 논의는
저렴하지만 false negatives를 생성할 가능성이 비교적 높은
관행에서 시작하여, 계산 비용은 더 높지만 false negatives의
위험이 낮은 관행으로 올라간다.
5.3.1. 단순 문자열 비교
두 IRI가 문자 문자열로 간주될 때 동일하다면, 이들이 동등하다고
결론내리는 것은 안전하다. 이러한 유형의 동등성 검사는 계산
비용이 매우 낮고, 특히 parsing 영역을 비롯한 다양한
애플리케이션에서 널리 사용된다. 또한 사용된 scheme과 독립적이고
네트워크에 접근하지 않고 빠르게 계산할 수 있는 IRI 동등성 질문에
대한 확정적인 답이 필요한 경우에도 사용된다. 그러한 경우의
예가 XML Namespaces([XMLNamespace])이다.
문자열의 동등성을 검사하려면 몇 가지 기본적인 주의가 필요하다.
이 절차는 흔히 "bit-for-bit" 또는 "byte-for-byte" 비교라고
불리지만, 이는 오해를 낳을 수 있다. 문자열의 동등성 검사는 보통
문자열을 이루는 문자를 첫 문자부터 시작하여 쌍으로 비교하고,
Duerst & Suignard Standards Track [Page 23]
RFC 3987 Internationalized Resource Identifiers January 2005
두 문자열이 모두 소진되고 모든 문자가 같다고 확인될 때까지,
문자 쌍이 서로 다르다고 비교될 때까지, 또는 한 문자열이 다른
문자열보다 먼저 소진될 때까지 진행하는 방식에 기반한다.
이러한 문자 비교는 각 문자 쌍이 비교 가능한 인코딩 형식에 놓여
있어야 함을 요구한다. 예를 들어 한 IRI가 UTF-8 인코딩 형식의
바이트 배열에 저장되어 있고 두 번째 IRI가 UTF-16 인코딩 형식에
저장되어 있다면, bit-for-bit 비교를 단순하게 적용하면 오류가
발생한다. byte-for-byte 또는 bit-for-bit 기준보다는
character-for-character 기준의 동등성을 말하는 것이 더 낫다.
실제적으로는 공통 문자 인코딩 형식으로 변환한 뒤 codepoint별로
character-by-character 비교를 수행해야 한다. 문자별로 비교할 때
비교 함수는 IRI를 URI로 매핑해서는 안 된다(MUST NOT). 그러한
매핑은 추가적인 허위 동등성을 만들 수 있기 때문이다. 따라서 이
IRI가 식별자로 사용될 가능성이 조금이라도 있다면, IRI는 전송 중에
수정되어서는 안 된다(SHOULD NOT).
false negatives는 IRI alias의 생성과 사용으로 인해 발생한다.
불필요한 alias는 비교 방법과 관계없이, 이미 정규화된 형식(즉,
아래에 설명된 대로 정규화가 적용된 뒤 생성될 형식과 동일한
형식)으로 IRI 참조를 일관되게 제공함으로써 줄일 수 있다.
프로토콜과 데이터 형식은 흔히, 사람과 구현이 자기 자신에게 가장
이로운 방향으로 IRI 참조를 일관되게 제공하거나, 적어도 추가
정규화에서 얻을 수 있는 효율성을 무효화할 만큼 충분히 일관되게
제공할 것이라는 이론에 기반하여, 일부 IRI 비교를 단순 문자열
비교로 제한한다.
5.3.2. 구문 기반 정규화
구현은 false negatives의 가능성을 줄이기 위해 이 명세가 제공하는
정의에 기반한 논리를 사용할 수 있다. 이 처리는 character-for-
character 문자열 비교보다 비용이 적당히 더 높다. 예를 들어 이
접근법을 사용하는 애플리케이션은 다음 두 IRI를 동등한 것으로
합리적으로 간주할 수 있다.
example://a/b/c/%7Bfoo%7D/rosé
eXAMPLE://a/./b/../b/%63/%7bfoo%7d/ros%C3%A9
browser와 같은 Web user agent는 보통 캐시된 응답을 사용할 수
있는지 판단할 때 이러한 유형의 IRI 정규화를 적용한다. 구문 기반
정규화에는 case normalization, character normalization,
percent-encoding normalization, 그리고 dot-segments 제거와 같은
기법이 포함된다.
Duerst & Suignard Standards Track [Page 24]
RFC 3987 Internationalized Resource Identifiers January 2005
5.3.2.1. 대소문자 정규화
모든 IRI에 대해, percent-encoding triplet 안의 16진 숫자(예:
"%3a"와 "%3A")는 대소문자를 구분하지 않으므로 A - F의 숫자에는
대문자를 사용하도록 정규화하는 것이 좋다.
IRI가 generic syntax의 구성 요소를 사용하는 경우, component
syntax equivalence rules가 항상 적용된다. 즉 scheme과 US-ASCII만
사용하는 host는 대소문자를 구분하지 않으므로 소문자로 정규화하는
것이 좋다. 예를 들어 URI "HTTP://www.EXAMPLE.com/"은
"http://www.example.com/"과 동등하다. IDN인 IRI 구성 요소의
비ASCII 문자에 대한 대소문자 동등성은 section 5.3.3에서
논의한다. 다른 generic syntax 구성 요소는 scheme에서 달리
정의하지 않는 한 대소문자를 구분한다고 가정한다.
비ASCII 문자를 포함하는 대소문자 비구분 구문 구성 요소를 허용하는
scheme을 만드는 것은 피해야 한다. 비ASCII 문자의 대소문자
정규화는 문화에 따라 달라질 수 있으며 항상 복잡한 작업이다.
유일한 예외는 문자 정규화가 case folding에서 파생된 매핑 단계를
포함하는 비ASCII host name에 관한 것이다.
5.3.2.2. 문자 정규화
Unicode Standard [UNIV4]는 다양한 목적을 위해 문자 시퀀스 사이의
여러 동등성을 정의한다. Unicode Standard Annex #15 [UTR15]는
이러한 동등성을 위한 다양한 Normalization Forms를 정의하며,
특히 Normalization Form C(NFC, Canonical Decomposition 뒤에
Canonical Composition)와 Normalization Form KC(NFKC,
Compatibility Decomposition 뒤에 Canonical Composition)를
정의한다.
IRI의 동등성은 두 IRI를 비교할 때 문자 정규화를 적용하기보다
IRI가 적절히 사전 문자 정규화되어 있다는 가정에 의존해야 한다
(MUST). 예외는 비디지털 형식에서 변환하는 경우와 비UCS 기반 문자
인코딩에서 UCS 기반 문자 인코딩으로 변환하는 경우이다. 이러한
경우 상호 운용성을 위해 NFC 또는 NFC를 사용하는 normalizing
transcoder를 사용해야 한다(MUST). false negatives와 transcoding
문제를 피하기 위해 IRI는 NFC를 사용하여 생성하는 것이 좋다
(SHOULD). NFKC를 사용하면 더 많은 문제를 피할 수 있다. 예를 들어
전각 라틴 문자 대신 반각 라틴 문자를 선택하고, 반각 Katakana 대신
전각 Katakana를 선택하는 식이다.
예를 들어 "http://www.example.org/résumé.html" (XML
Notation에서)은 NFC이다. 반면
"http://www.example.org/résumé.html"은 NFC가 아니다.
Duerst & Suignard Standards Track [Page 25]
RFC 3987 Internationalized Resource Identifiers January 2005
전자는 미리 조합된 e-acute 문자를 사용하고, 후자는 "e" 문자 뒤에
combining acute accent를 사용한다. 두 사용 방식은 [UNIV4]에서
canonical equivalent로 정의된다.
Note: 특정 문자 시퀀스가 문자 정규화와 관련해 어떻게 처리되는지
알 수 없으므로, 제3자가 IRI를 임의로 정규화하도록 허용하는 것은
부적절하다. 이는 리소스가 생성될 때 그 IRI가 가능한 한 문자
정규화되어야 한다(즉 NFC 또는 심지어 NFKC)는 권고와 모순되지
않는다. 이는 대문자/소문자 문제와 유사하다. URI의 일부 부분은
대소문자를 구분하지 않는다(domain name). 다른 부분에서는
대소문자를 구분하는지, 구분하지 않는지, 또는 그 중간인지가
명확하지 않다(예: 잘못된 대소문자를 사용했을 때 직접적인 부정
결과 대신 여러 선택지를 제공하지만 대소문자를 구분하는 경우).
가장 좋은 방법은 생성자가 합리적인 대소문자 사용을 선택하고,
URI를 전송할 때 대소문자를 절대 변경하지 않는 것이다.
다양한 IRI scheme은 Internationalized Domain Names (IDN)
[RFC3490]의 사용을 ireg-name 부분 또는 다른 곳에서 허용할 수
있다. Character Normalization은 IDN에도 적용되며, 이는
section 5.3.3에서 논의한다.
5.3.2.3. Percent-Encoding 정규화
percent-encoding 메커니즘([RFC3986]의 section 2.1)은 그 외에는
동일한 IRI 사이의 차이를 자주 만들어내는 원천이다. 위에서 언급한
대소문자 정규화 문제 외에도, 일부 IRI 생성자는 percent-encoding이
필요하지 않은 옥텟을 percent-encode하여, 인코딩되지 않은 대응물과
동등한 IRI를 만들어낸다. 이러한 IRI는 [RFC3986]의 section 2.3에
설명된 것처럼 unreserved 문자에 해당하는 모든 percent-encoded
octet sequence를 디코딩하여 정규화하는 것이 좋다.
실제 resolution의 경우, percent-encoding의 차이(예약 문자의
percent-encoding 제외)는 항상 같은 리소스로 이어져야 한다(MUST).
예를 들어 "http://example.org/~user", "http://example.org/%7euser",
그리고 "http://example.org/%7Euser"는 같은 리소스로 resolve되어야
한다.
이러한 종류의 동등성을 검사하려면, 비교할 두 IRI의
percent-encoding을 정렬해야 한다. 예를 들어 두 IRI를 모두 URI로
변환하고(section 3.1 참조), 결과 URI에서 escape 차이를 제거하며,
percent-encoding의 16진 문자의 대소문자가 항상 동일하도록
보장한다(가급적 대문자). IRI가 다른 애플리케이션으로 전달되거나
다른 방식으로 계속 사용될 경우에는 원래 형식이 보존되어야 한다
(MUST). 여기에 설명된 변환은 로컬 비교를 위해서만 수행되어야 한다.
Duerst & Suignard Standards Track [Page 26]
RFC 3987 Internationalized Resource Identifiers January 2005
5.3.2.4. Path Segment 정규화
완전한 path segment "."와 ".."는 relative reference([RFC3986]의
section 4.1) 안에서만 사용되도록 의도되었고, reference
resolution 과정([RFC3986]의 section 5.2)의 일부로 제거된다.
그러나 일부 구현은 reference가 이미 IRI인 경우 reference
resolution이 필요하지 않다고 잘못 가정하여, dot-segments가
non-relative path에 나타날 때 이를 제거하지 못할 수 있다. IRI
normalizer는 [RFC3986]의 section 5.2.4에 설명된 대로
remove_dot_segments 알고리즘을 path에 적용하여 dot-segments를
제거하는 것이 좋다.
5.3.3. 스킴 기반 정규화
IRI의 구문과 의미는 각 scheme의 정의 명세에 설명된 대로 scheme마다
다르다. 구현은 추가 처리 비용을 들여 false negatives의 가능성을
줄이기 위해 scheme-specific rules를 사용할 수 있다. 예를 들어
"http" scheme은 authority component를 사용하고, 기본 port가
"80"이며, empty path를 "/"와 동등한 것으로 정의하므로, 다음 네
IRI는 동등하다.
http://example.com
http://example.com/
http://example.com:/
http://example.com:80/
일반적으로 empty path를 가진 authority의 generic syntax를 사용하는
IRI는 "/" path로 정규화하는 것이 좋다. 마찬가지로 port가 비어
있거나 scheme의 기본값인 명시적 ":port"는 port와 그 ":" 구분자가
생략된 경우와 동등하므로 scheme-based normalization에 의해
제거되는 것이 좋다. 예를 들어 위의 두 번째 IRI가 "http" scheme의
normal form이다.
정규화가 scheme에 따라 달라지는 또 다른 경우는 empty authority
component 또는 empty host subcomponent의 처리이다. 많은 scheme
명세에서는 empty authority 또는 host를 오류로 간주하지만, 다른
명세에서는 이를 "localhost" 또는 최종 사용자의 host와 동등한
것으로 간주한다. scheme이 authority의 기본값을 정의하고 그
기본값에 대한 IRI reference가 필요한 경우, uniformity, brevity,
Duerst & Suignard Standards Track [Page 27]
RFC 3987 Internationalized Resource Identifiers January 2005
그리고 internationalization을 위해 reference는 empty authority로
정규화되는 것이 좋다. 그러나 userinfo 또는 port subcomponents 중
하나라도 비어 있지 않다면, host가 기본값과 일치하더라도 명시적으로
제공되어야 한다.
정규화는 scheme 명세가 그렇게 할 수 있도록 허용하지 않는 한,
관련 구성 요소가 비어 있을 때 구분자를 제거해서는 안 된다. 예를
들어 IRI "http://example.com/?"는 위 예시 중 어떤 것과도 동등하다고
가정할 수 없다. 마찬가지로 userinfo subcomponent 안의 구분자의
존재 여부는 보통 그 해석에 중요하다. fragment component는 어떤
scheme-based normalization의 대상도 아니다. 따라서 suffix "#"
만 다른 두 IRI는 scheme과 관계없이 서로 다른 것으로 간주된다.
일부 IRI scheme은 Internationalized Domain Names (IDN) [RFC3490]의
사용을 ireg-name 부분 또는 다른 곳에서 허용할 수 있다. IRI에서
사용되는 경우, 이러한 이름은 [RFC3490]에 정의된 ToASCII
연산을 "UseSTD3ASCIIRules"와 "AllowUnassigned" 플래그와 함께
사용하여 검증하는 것이 좋다(SHOULD). 유효하지 않은 IDN을 포함하는
IRI는 성공적으로 resolve될 수 없다. 검증된 IRI의 IDN 구성 요소는
Nameprep process [RFC3491]를 사용하여 문자 정규화하는 것이 좋다
(SHOULD). 그러나 가독성을 위해 ASCII Compatible Encoding (ACE)로
변환하지 않는 것이 좋다(SHOULD NOT).
Scheme-based normalization은 IDN 구성 요소와 punycode로의 변환을
동등한 것으로 간주할 수도 있다. 예를 들어
"http://résumé.example.org"는
"http://xn--rsum-bpad.example.org"와 동등한 것으로 간주될 수 있다.
다른 scheme-specific normalization도 가능하다.
5.3.4. 프로토콜 기반 정규화
false negatives의 발생을 줄이기 위한 상당한 노력은 web spiders에
대해 비용 효율적인 경우가 많다. 따라서 이들은 IRI 비교에서 훨씬
더 공격적인 기법을 구현한다. 예를 들어 다음과 같은 IRI가
http://example.com/data
trailing slash만 다른 IRI로 redirect되는 것을 관찰하면
http://example.com/data/
앞으로는 두 IRI를 동등한 것으로 간주할 가능성이 높다. 이러한
기법은 리소스 접근 결과와 해당 scheme의 dereference algorithm의
Duerst & Suignard Standards Track [Page 28]
RFC 3987 Internationalized Resource Identifiers January 2005
일반 관례 양쪽에서 동등성이 명확히 표시되는 경우에만 적절하다
(이 경우에는 relative reference 문제를 피하기 위해 HTTP origin
server가 redirection을 사용하는 경우).
6. IRI의 사용
6.1. IRI에서 허용되는 UCS 문자에 대한 제한
이 절은 section 2.2와 section 4.1에 제시된 것 이외에 IRI에서
사용할 수 있는 문자와 문자 시퀀스에 대한 제한을 논의한다. 이
절의 고려 사항은 IRI를 생성할 때와 URI를 IRI로 변환할 때 관련이
있다.
a. 각 IRI 구성 요소에서 허용되는 문자 레퍼토리는 그 구성 요소의
정의에 의해 제한된다. 예를 들어 scheme component의 정의는
US-ASCII를 넘어서는 문자를 허용하지 않는다.
(Note: URI 관행에 따라, 일반 IRI 소프트웨어는 이러한 제한을
검사할 수 없으며 검사해서도 안 된다.)
b. UCS에는 강한 시각적 유사성을 가진 문자 영역이 많이 포함되어
있다. transcription 오류의 가능성 때문에 이들도 피하는 것이
좋다. 여기에는 라틴 문자의 전각 동등 문자, 일본어용 반각
Katakana 문자, 그리고 그 밖의 많은 문자가 포함된다. 또한
[RFC3491]에서 제외된 "space", "delims", "unwise" 문자와
유사해 보이는 많은 문자도 포함된다.
추가 정보는 [UNIXML]에서 확인할 수 있다. [UNIXML]은 identifier의
문맥이 아니라 running text의 문맥에서 작성되었다. 그럼에도
불구하고 IRI에 적절하지 않은 여러 문자 범주를 논의한다.
6.2. 소프트웨어 인터페이스와 프로토콜
IRI는 문자 시퀀스로 정의되어 있지만, URI를 위한 소프트웨어
인터페이스는 보통 옥텟 시퀀스나 다른 종류의 code unit에 대해
동작한다. 따라서 소프트웨어 인터페이스와 프로토콜은 어떤 문자
인코딩이 사용되는지 정의해야 한다(MUST).
IRI-capable 구성 요소와 URI-only 구성 요소 사이의 중간 소프트웨어
인터페이스는 IRI-capable 구성 요소에서 URI-only 구성 요소로
전달할 때 section 3.1에 따라 IRI를 매핑해야 한다(MUST). 이
매핑은 가능한 한 늦게 적용하는 것이 좋다(SHOULD). IRI를 처리할 수
있는 것으로 알려진 구성 요소 사이에서는 적용하지 않는 것이 좋다
(SHOULD NOT).
Duerst & Suignard Standards Track [Page 29]
RFC 3987 Internationalized Resource Identifiers January 2005
6.3. 문서와 프로토콜에서 URI와 IRI의 형식
URI를 전달하는 문서 형식은 IRI의 전달을 허용하도록 업그레이드해야
할 수 있다. 문서 전체가 native character encoding을 가지는 경우,
IRI도 이 문자 인코딩으로 인코딩되어야 하며 parser 또는
interpreter에 의해 그에 따라 변환되어야 한다(MUST). native
character encoding으로 표현할 수 없는 IRI 문자는 그러한 규약을
사용할 수 있는 경우 문서 형식의 escaping convention을 사용하여
escape하는 것이 좋다(SHOULD). 또는 section 3.1에 따라
percent-encode할 수도 있다(MAY). 예를 들어 HTML 또는 XML에서는
numeric character reference를 사용하는 것이 좋다(SHOULD). 문서
전체가 native character encoding을 가지고 있고 그 문자 인코딩이
UTF-8이 아닌 경우, IRI를 UTF-8 문자 인코딩으로 문서 안에 넣어서는
안 된다(MUST NOT).
Note: 일부 형식은 이미 IRI를 수용하지만 다른 용어를 사용한다.
HTML 4.0 [HTML4]은 IRI에서 URI로의 변환을 error-avoiding
behavior로 정의한다. XML 1.0 [XML1], XLink [XLink],
XML Schema [XMLSchema], 그리고 이를 기반으로 하는 명세들은
IRI를 허용한다. 또한 관련된 모든 새로운 W3C 형식과 프로토콜은
IRI를 처리해야 할 것으로 예상된다 [CharMod].
6.4. 원래 문자를 인코딩하기 위한 UTF-8 사용
이 절은 section 1.2의 point c)에 대한 세부 사항을 논의하고
예시를 제공한다. IRI를 사용할 수 있으려면 해당 IRI에 대응하는
URI가 원래 문자를 UTF-8을 사용하여 옥텟으로 인코딩해야 한다.
이는 URI scheme의 모든 URI에 대해 지정될 수도 있고, 원래 문자를
인코딩하는 방법을 지정하지 않는 scheme의 개별 URI에 적용될 수도
있다. 이는 전체 URI에 적용될 수도 있고 일부 부분에만 적용될 수도
있다. 문자를 URI로 인코딩하는 것에 대한 배경 정보는
[RFC3986]의 section 2.5도 참조하라.
새로운 URI scheme의 경우 UTF-8 사용은 [RFC2718]에서 권장된다.
UTF-8이 이미 사용되는 예로는 URN syntax [RFC2141], IMAP URLs
[RFC2192], 그리고 POP URLs [RFC2384]가 있다. 반면 HTTP URL
scheme은 원래 문자를 인코딩하는 방법을 지정하지 않기 때문에,
일부 HTTP URL만 대응하지만 서로 다른 IRI를 가질 수 있다.
예를 들어 URI가
"http://www.example.org/r%C3%A9sum%C3%A9.html"인 문서의 경우,
대응하는 IRI(XML notation으로, section 1.4 참조)를 구성할 수
있다:
"http://www.example.org/résumé.html" ("é";는
e-acute 문자를 나타내고, "%C3%A9"는 그 문자의 UTF-8 인코딩 및
percent-encoded 표현이다). 반면 URI가
Duerst & Suignard Standards Track [Page 30]
RFC 3987 Internationalized Resource Identifiers January 2005
"http://www.example.org/r%E9sum%E9.html"인 문서의 경우,
percent-encoding octets가 UTF-8에 기반하지 않으므로 IRI의 실제
문자로 변환할 수 없다.
이는 대부분의 URI scheme에 대해, IRI와 함께 동작하도록 scheme
정의를 업그레이드할 필요가 없다는 뜻이다. 업그레이드가 의미 있는
주요 경우는 scheme 정의 또는 scheme의 특정 구성 요소가 비ASCII
문자/옥텟을 percent-encoding을 통해 포함할 수 있는 규정 없이
US-ASCII 문자 사용으로 엄격하게 제한되어 있거나, scheme 정의가
현재 비ASCII 문자 인코딩을 위해 매우 scheme-specific한 규정을
사용하는 경우이다. 그 예가 mailto: scheme [RFC2368]이다.
이 명세는 어떤 방식으로도 어떤 scheme 명세도 업그레이드하지
않는다. 이는 별도로 수행되어야 한다. 또한 "IRI scheme"이라는 것은
존재하지 않는다는 점에 유의하라. 모든 IRI는 URI scheme을 사용하며,
모든 URI scheme은 IRI와 함께 사용될 수 있다. 어떤 경우에는 변환
없이 URI를 IRI로 직접 사용하는 방식으로만 가능하더라도 그렇다.
URI scheme은 scheme-specific URI의 구문에 제한을 부과할 수 있다.
즉 generic URI syntax [RFC3986]에서 허용되는 URI가 URI scheme
명세가 부과한 더 좁은 구문 제약 때문에 허용되지 않을 수 있다.
URI scheme 정의는 generic URI syntax의 구문 제한을 넓힐 수 없다.
그렇지 않으면 scheme-specific syntactic constraints를 만족하지만
generic URI syntax의 syntactic constraints를 만족하지 않는 URI를
생성할 수 있게 된다. 그러나 URI scheme 명세가 부과하는 추가
구문 제약은 IRI에 적용된다. section 3.1에 정의된 매핑 결과로
나온 대응 URI는 generic URI syntax의 구문 제한과 대응하는 URI
scheme 명세가 부과하는 더 좁은 제한 아래에서 유효한 URI여야 하기
때문이다(MUST).
UTF-8 사용 요구 사항은 URI의 모든 부분에 적용된다(ireg-name
부분은 잠재적 예외이며, section 3.1 참조). 그러나 넓은 범위의
문자를 직접 표현할 수 있는 IRI의 능력이 IRI(또는 IRI reference)의
일부 부분에서만 사용될 수도 있다. IRI의 다른 부분은 US-ASCII
문자만 포함할 수도 있고, UTF-8에 기반하지 않을 수도 있다. 이들은
다른 문자 인코딩에 기반할 수도 있고, raw binary data를 직접
인코딩할 수도 있다([RFC2397]도 참조).
예를 들어
"http://www.example.org/r%E9sum%E9.xml#r%C3%A9sum%C3%A9"라는 URI
reference를 가질 수 있다. 여기서 document name은 server settings에
기반하여 iso-8859-1로 인코딩되지만, fragment identifier는
Duerst & Suignard Standards Track [Page 31]
RFC 3987 Internationalized Resource Identifiers January 2005
[XPointer]에 따라 UTF-8로 인코딩된다. 위 URI에 대응하는 IRI는
(XML notation으로)
"http://www.example.org/r%E9sum%E9.xml#résumé";이다.
유사한 고려 사항은 query parts에도 적용된다. IRI의 기능(즉,
비ASCII 문자를 포함할 수 있는 능력)은 query part가 UTF-8로
인코딩된 경우에만 사용할 수 있다.
6.5. 상대 IRI 참조
base에 대한 relative IRI reference의 처리는 간단하게 다루어진다.
[RFC3986]의 알고리즘을 직접 적용할 수 있으며, IRI reference에서
추가로 허용되는 문자를 URI reference의 unreserved 문자와 같은
방식으로 취급한다.
7. URI/IRI 처리 지침 (정보 제공)
이 정보 제공 절은 현재 URI를 처리하는 동일한 소프트웨어 구성
요소와 작업에서 IRI를 지원하기 위한 지침을 제공한다. 즉 URI를
처리하는 소프트웨어 인터페이스, 사용자가 URI를 입력할 수 있게
하는 소프트웨어, URI를 만들거나 생성하는 소프트웨어, URI를
표시하는 소프트웨어, URI를 전달하는 형식과 프로토콜, 그리고 URI를
해석하는 소프트웨어이다. 이들은 모두 IRI와 제대로 동작하기 전에
수정이 필요할 수 있다. 이 절의 고려 사항은 URI reference와 IRI
reference에도 적용된다.
7.1. URI/IRI 소프트웨어 인터페이스
URI-handling API 및 URI를 전달하는 프로토콜과 같이 URI를 처리하는
소프트웨어 인터페이스에는 IRI를 전달하도록 설계된 인터페이스와
프로토콜 요소가 필요하다.
API 또는 프로토콜의 현재 처리가 US-ASCII에 기반하는 경우, IRI의
문자 인코딩으로 UTF-8이 권장된다. UTF-8은 US-ASCII와 호환되고
[RFC2277]의 권고와 일치하며 URI로의 변환을 쉽게 만들기 때문이다.
어떤 경우든 API 또는 프로토콜 정의는 사용할 문자 인코딩을
명확하게 정의해야 한다.
URI-only 구성 요소에서 IRI-capable 구성 요소로의 전달에는 매핑이
필요하지 않지만, 위 section 3.2에 설명된 변환을 수행할 수 있다.
이 역변환이 올바르게 수행될 수 없을 가능성이 있는 경우에는 이를
수행하지 않는 것이 바람직하다.
Duerst & Suignard Standards Track [Page 32]
RFC 3987 Internationalized Resource Identifiers January 2005
7.2. URI/IRI 입력
일부 구성 요소는 사용자가 typing 또는 dictation 등을 통해 URI를
시스템에 입력할 수 있게 한다. 이 소프트웨어는 IRI 입력을 허용하도록
업데이트되어야 한다.
IRI의 시각적 표현(어떤 visual display에서 어떤 순서로 된 glyph의
시퀀스)을 보거나 IRI를 듣는 사람은 사용자의 언어에 맞는 문자 입력
방법을 사용하여 IRI를 입력할 것이다. 사용되는 script와 input
method에 따라 이는 어느 정도 복잡한 과정일 수 있다.
IRI 입력 과정은 가능한 한 section 2.2에 정의된 제한이 충족되도록
보장해야 한다. 이는 적절한 input methods 또는 그 variants/settings
를 선택하거나, 입력되는 문자를 적절히 변환하거나, 변환될 수 없는
문자를 제거하거나, 사용자에게 warning 또는 error message를
발행함으로써 수행될 수 있다.
variant settings의 예로, East Asian Languages용 input method
editors는 보통 라틴 문자와 관련 문자를 전각 또는 반각 버전으로
입력할 수 있게 한다. IRI 입력의 경우, input method editor는 반각
라틴 문자와 punctuation, 그리고 전각 Katakana를 생성하도록 설정되는
것이 좋다.
주로 또는 오직 URI/IRI 입력에 사용되는 input field는 사용자가
URI로 매핑된 IRI를 볼 수 있도록 허용할 수 있다. IRI 입력이 자주
이루어지는 곳은 URI로 매핑된 IRI를 볼 수 있는 가능성을 제공할 수
있다. 이는 사용자가 사용하는 일부 소프트웨어가 아직 IRI를
받아들이지 않을 때 도움이 된다.
URI는 처리하지만 IRI는 처리하지 않는 구성 요소와 인터페이스하는
IRI input component는 이러한 구성 요소에 전달하기 전에 IRI를 URI로
매핑해야 한다.
오른쪽에서 왼쪽 문자를 가진 IRI의 입력에 대해서는 section 4.3을
참조하기 바란다.
7.3. 애플리케이션 간 URI/IRI 전달
많은 애플리케이션, 특히 mail user agent는 plain text에 나타나는
URI를 감지하려고 한다. 이를 위해 URI 구문에 기반한 몇 가지
heuristics를 사용한다. 그런 다음 사용자가 그러한 URI를 클릭하고
해당 리소스를 적절한(보통 scheme-dependent) 애플리케이션에서
가져올 수 있게 한다.
Duerst & Suignard Standards Track [Page 33]
RFC 3987 Internationalized Resource Identifiers January 2005
그러한 애플리케이션은 IRI 구문을 heuristics의 기반으로 사용하도록
업그레이드되어야 한다. 특히 비ASCII 문자를 IRI의 끝을 나타내는
표시로 받아들여서는 안 된다. 그러한 애플리케이션은 또한 감지된
IRI를, IRI가 나타난 문서 또는 애플리케이션의 문자 인코딩에서
system-wide IRI invocation mechanism이 사용하는 문자 인코딩으로
올바르게 변환하거나, system-wide invocation mechanism이 URI만
받아들이는 경우에는 section 3.1에 따라 URI로 변환하도록 보장해야
한다.
clipboard는 URI와 IRI를 한 애플리케이션에서 다른 애플리케이션으로
전달하는 또 다른 자주 사용되는 방법이다. 대부분의 플랫폼에서
clipboard는 여러 언어와 script의 텍스트를 저장하고 전달할 수 있다.
올바르게 사용되면 clipboard는 바이트가 아니라 문자를 전달하며,
이는 IRI에 대해 올바른 동작을 수행한다.
7.4. URI/IRI 생성
Internet을 통해 리소스를 제공하는 시스템은, 그 리소스가 논리적
이름을 가지는 경우, 때때로 제공하는 리소스에 대한 URI를 자동으로
생성한다. 예를 들어 일부 HTTP server는 file directory에 대한
directory listing을 생성한 뒤 생성된 URI에 대해 파일로 응답할 수
있다.
많은 legacy character encoding이 여러 파일 시스템에서 사용되고
있다. 현재 배포된 많은 시스템은 URI를 생성하기 전에 underlying
system의 local character representation을 변환하지 않는다.
최대한의 상호 운용성을 위해 resource identifier를 생성하는 시스템은
적절한 변환을 수행하는 것이 좋다. 예를 들어 file system에
"résumé.html"이라는 이름의 파일이 있다면, server는 이를
URI에서 "r%C3%A9sum%C3%A9.html"로 노출하는 것이 좋다. 이렇게 하면
로컬에서 파일 이름이 UTF-8 이외의 문자 인코딩으로 보관되어
있더라도 IRI에서 "résumé.html"을 사용할 수 있다.
이 권고는 특히 HTTP server에 적용된다. FTP server의 경우에도
유사한 고려 사항이 적용된다. [RFC2640]을 참조하라.
7.5. URI/IRI 선택
어떤 경우에는 resource owner와 publisher가 자신의 리소스를
식별하는 데 사용되는 IRI를 제어할 수 있다. 이러한 제어는 대체로
file name과 같은 resource name을 직접 제어함으로써 실행된다.
Duerst & Suignard Standards Track [Page 34]
RFC 3987 Internationalized Resource Identifiers January 2005
이러한 경우에는 쉽게 혼동되는 IRI 선택을 피하는 것이 권장된다.
예를 들어 US-ASCII에서 소문자 ell("l")은 숫자 one("1")과 쉽게
혼동되고, 대문자 oh("O")는 숫자 zero("0")와 쉽게 혼동된다.
publisher는 "br0ken" 또는 "1ame" identifier로 사용자를 혼란스럽게
하는 것을 피해야 한다.
US-ASCII 레퍼토리 밖에서는 혼동 가능성이 훨씬 더 많다. 전체
지침을 여기에 포함하기에는 너무 길다. 이름이 단일 script의 문자로
제한되는 한, 해당 script 또는 language의 native writer가 언제
모호성이 나타날 수 있고 이를 어떻게 피할 수 있는지 가장 잘 안다.
낯선 사람에게는 모호해 보일 수 있는 것이 평균적인 native user에게는
완전히 명백할 수 있다. 반면 어떤 경우에는 UCS가 compatibility
reasons로 variants를 포함한다. 예를 들어 typographic purposes를
위한 것이다. 이러한 것은 가능하면 피해야 한다. 예외가 있을 수는
있지만, 새로 생성되는 resource name은 일반적으로 NFKC [UTR15]에
있어야 한다(이는 곧 NFC에도 있음을 의미한다).
예를 들어 UCS는 compatibility reasons로 U+FB01에 "fi" ligature를
포함한다. 가능하면 IRI는 "fi" ligature가 아니라 두 글자 "f"와
"i"를 사용해야 한다. 후자가 사용될 수 있는 예는 "fi" ligature를
포함하여 쓰인 단어를 명시적으로 검색하기 위한 IRI의 query part이다.
특정 경우에는 서로 다른 script의 문자가 동일하게 보일 가능성이
있다. 가장 잘 알려진 예는 라틴 "A", 그리스 "Alpha", 키릴 "A"의
유사성이다. 이러한 경우를 피하기 위해, 단일 구성 요소의 모든
문자가 어떤 주어진 언어에서 함께 사용되는 IRI만 생성하는 것이
좋다. 이는 보통 이러한 모든 문자가 같은 script에 속한다는 뜻이지만,
일본어처럼 서로 다른 script의 문자를 섞는 언어도 있다. 이는 위
예시에서 글자와 숫자를 구별하는 데 사용된 heuristics와 유사하다.
또한 라틴, 그리스, 키릴 문자의 경우 대문자를 사용하는 것보다
소문자를 사용하는 것이 모호성을 더 적게 만든다.
7.6. URI/IRI 표시
rendering software가 사용 가능한 layout 및 font resources를 사용해
IRI의 비ASCII 부분을 올바르게 표시할 것으로 예상되지 않는 상황에서는,
이러한 부분을 표시하기 전에 percent-encode하는 것이 좋다.
Bidi IRI 표시의 경우 section 4.1을 참조하기 바란다.
Duerst & Suignard Standards Track [Page 35]
RFC 3987 Internationalized Resource Identifiers January 2005
7.7. URI와 IRI의 해석
IRI를 로컬 리소스의 이름으로 해석하는 소프트웨어는 여러 형식의
IRI를 받아들이고 이를 적절한 local resource name으로 변환하고
매칭해야 한다.
첫째, 여러 표현에는 프로토콜의 native character encoding으로 된
IRI와 그 URI counterpart가 모두 포함된다.
둘째, UTF-8 이외의 문자 인코딩에 기반하여 구성된 URI가 포함될 수
있다. 이러한 URI는 이 명세를 준수하지 않고 legacy character
encoding을 사용하여 비ASCII 문자를 URI로 변환하는 user agent에
의해 생성될 수 있다. 이것이 필요한지, 어떤 문자 인코딩을 포괄할지는
로컬에서 사용되는 legacy character encodings와 다양한 버전의 user
agent 분포 같은 여러 요인에 달려 있다. 예를 들어 일본어용
소프트웨어는 UTF-8 외에도 Shift_JIS 및/또는 EUC-JP의 URI를
받아들일 수 있다.
셋째, 더 사용자 친화적이고 전송 오류에 견고하도록 추가 매핑을
포함할 수 있다. 이는 일부 server가 현재 URI를 대소문자 구분 없이
처리하거나 철자 오류를 고려하기 위해 추가 matching을 수행하는
방식과 유사하다. US-ASCII 레퍼토리를 넘어서는 문자에 대해서는,
예를 들어 수신된 IRI 또는 resource name의 accent를 무시하는 것이
여기에 포함될 수 있다. 이러한 매핑은 case mappings를 포함하여
언어에 의존한다는 점에 유의하라.
너무 많은 매핑을 고려하면 리소스를 모호하지 않게 식별하기 어려울
수 있다. 그러나 IRI의 percent-encoded 부분과 percent-encoded되지
않은 부분은 항상 명확하게 구별할 수 있다. 또한 UTF-8의 규칙성
([Duerst97] 참조)은 충돌 가능성을 처음 보이는 것보다 낮게 만든다.
7.8. 업그레이드 전략
이 권고가 이미 많은 인스턴스가 배포된 소프트웨어에 추가 제약을
부과하는 경우, 업그레이드를 신중하게 도입하고 다양한 상호 의존성을
인식하는 것이 중요하다.
IRI를 올바르게 해석할 수 없다면, IRI를 만들거나 생성하거나 전달해서는
안 된다. 이는 IRI를 받아들이도록 URI interpreting software를
업그레이드하는 것이 가장 높은 우선순위를 가져야 함을 시사한다.
반면 하나의 IRI는, 입력되고 매우 널리 전달될 수는 있지만, 미리
알려진 하나 또는 매우 적은 수의 interpreter에 의해서만 해석된다.
Duerst & Suignard Standards Track [Page 36]
RFC 3987 Internationalized Resource Identifiers January 2005
따라서 IRI는 IRI를 입력하고 전달할 수 있도록 소프트웨어를 광범위하게
업그레이드할 때 가장 큰 이점을 얻는다. 그러나 개별 IRI가 게시되기
전에, 여러 버전의 entry 및 transport software에서 수신될 것으로
예상되는 형식을 포괄하도록 대응하는 interpreting software를
업그레이드하는 데 주의해야 한다.
local character encoding을 사용하는 대신 IRI를 생성하도록 generating
software를 업그레이드하는 것은 service가 IRI를 받아들이도록
업그레이드된 뒤에만 이루어져야 한다. 마찬가지로 service가 IRI를
받아들이고 intervening infrastructure와 protocol이 이를 안전하게
전달한다고 알려진 경우에만 IRI를 생성하는 것이 좋다.
표시를 위해 URI에서 IRI로 변환하는 소프트웨어는 표시 결과를 볼
사용자 집단에 업그레이드된 entry software가 널리 배포된 뒤에만
업그레이드하는 것이 좋다.
문자 인코딩을 자유롭게 선택할 수 있는 경우, 다른 인코딩 대신
UTF-8을 사용함으로써 IRI로 업그레이드하는 데 필요한 노력과 의존성을
줄일 수 있는 경우가 많다. 예를 들어 새로운 file-based Web server를
설정할 때 file name의 문자 인코딩으로 UTF-8을 사용하면 IRI로의
전환이 더 쉬워진다. 마찬가지로 새로운 Web form을 form page의 문자
인코딩으로 UTF-8을 사용하여 설정하면, 반환되는 query URI는
(사용자가 어떤 이유로 문자 인코딩을 변경하지 않는 한) UTF-8을
문자 인코딩으로 사용하므로 IRI와 호환된다.
이러한 권고를 종합하면, 상호 운용성 문제를 최소화하면서 US-ASCII
이외의 문자를 처리하기 위해 URI에서 IRI로 확장할 수 있게 된다.
URI scheme definition의 업그레이드에 관한 고려 사항은
section 6.4를 참조하라.
8. 보안 고려 사항
[RFC3986]에서 논의된 보안 고려 사항은 IRI에도 적용된다. 그에
더하여 다음 문제들은 IRI에 대해 특별한 주의가 필요하다.
잘못된 인코딩 또는 디코딩은 보안 문제로 이어질 수 있다. 특히
일부 UTF-8 decoder는 overlong byte sequence를 검사하지 않는다.
예를 들어 "/"는 UTF-8과 US-ASCII 모두에서 byte 0x2F로 인코딩되지만,
일부 UTF-8 decoder는 sequence 0xC0 0xAF를 "/"로 잘못 해석하기도
한다. "%C0%AF.."와 같은 sequence는
Duerst & Suignard Standards Track [Page 37]
RFC 3987 Internationalized Resource Identifiers January 2005
일부 security test를 통과한 뒤, UTF-8 decoder가 fault-tolerant하거나,
변환과 검사가 올바른 순서로 수행되지 않거나, reserved characters와
unreserved characters가 명확하게 구별되지 않는 경우 path에서 "/.."로
해석될 수 있다.
IRI에서는 "spoofing"이 발생할 수 있는 여러 방식이 있다. "Spoofing"
은 누군가가 사용자에게 동일하거나 유사하게 보이지만 다른 리소스를
가리키는 resource name을 추가할 수 있음을 의미한다. 추가된 리소스는
실제 리소스와 매우 유사하게 보임으로써 실제 리소스인 것처럼
가장할 수 있지만, 발견하기 어려울 수 있고 온갖 문제를 일으킬 수
있는 모든 종류의 변경을 포함할 수 있다. IRI의 대부분의 spoofing
가능성은 URI의 가능성을 확장한 것이다.
Spoofing은 여러 이유로 발생할 수 있다. 첫째, 사용자가 IRI를
입력하거나 legacy character encoding에서 IRI를 transcoding할 때의
normalization expectation 또는 실제 normalization이 server side에서
사용되는 normalization과 일치하지 않을 수 있다. 개념적으로 이는
case-insensitive web server 사용과 관련된 문제와 다르지 않다.
예를 들어 mixed-case name("http://big.example.com/PopularPage.html")을
가진 인기 있는 Web page는, 누군가가
"http://big.example.com/popularpage.html"을 만들 수 있다면 "spoofed"
될 수 있다. 그러나 정규화되지 않은 문자 시퀀스의 사용과 사용자
편의를 위한 추가 매핑의 사용은 spoofing 가능성을 높일 수 있다.
정규화되지 않은 이름으로 리소스를 생성할 수 있게 하는 프로토콜과
server는 이러한 공격에 특히 취약하다. 이는 관련 protocol, server,
또는 resource의 본질적인 보안 문제이며 IRI에만 국한된 것은 아니지만,
완전성을 위해 여기서 언급한다.
Spoofing은 domain name part나 path part와 같은 다양한 IRI 구성
요소에서 발생할 수 있다. domain name part에 특정한 고려 사항은
[RFC3491]을 참조하라. path part의 경우, 독립적인 사용자가 같은
sub area 안에 리소스를 생성할 수 있게 하는 site의 administrator는
spoofing을 검사하는 데 주의해야 할 수 있다.
Spoofing은 UCS에서 많은 문자가 매우 유사하게 보이기 때문에 발생할
수 있다. 자세한 내용은 Section 7.5에서 논의된다. 다시 말하지만,
이는 "br0ken" 또는 "1ame" URI를 사용하는 것과 같은 US-ASCII의
spoofing 가능성과 매우 유사하다.
Spoofing은 older user agent를 처리하기 위해 다양한 문자 인코딩에
기반한 percent-encoding을 가진 URI가 받아들여질 때 발생할 수 있다.
어떤 경우, 특히 Latin-based resource name의 경우, UTF-8로 인코딩된
이름이 legacy character encoding으로 해석되고 표시될 때 대부분
의미 없는 문자처럼 보이므로 이는 보통 쉽게 감지된다.
Duerst & Suignard Standards Track [Page 38]
RFC 3987 Internationalized Resource Identifiers January 2005
동시에 사용되는 문자 인코딩들이 유사한 구조를 가지지만 정확히 같은
인코딩을 가진 문자가 없는 경우, 감지는 더 어렵다.
Spoofing은 section 4.2의 제한을 따르지 않는 경우 bidirectional
IRI에서 발생할 수 있다. 동일한 시각적 표현이 서로 다른 논리적
표현으로 해석될 수 있고, 그 반대도 가능하다. 올바른 Unicode
bidirectional implementation을 사용하는 것도 매우 중요하다.
9. 감사의 말
이 문서의 많은 이전 버전(draft-masinter-url-i18n-xx)에서
공동 저자로 작업한 Larry Masinter에게 감사드린다.
여기서 다루는 문제에 대한 논의는 오래전에 시작되었다. 1995년
8월 HTML working group에는 "Globalizing URIs"라는 주제의 thread가
있었고, 1996년 7월 www-international mailing list에는
"Internationalization and URLs"라는 주제의 thread가 있었다. 또한
1995년 9월과 1997년 9월 Unicode conferences에서 ad-hoc meetings가
있었다.
문제와 가능한 해결책을 이해하고 세부 사항을 올바르게 만드는 데
도움을 준 Francois Yergeau, Matitiahu Allouche, Roy Fielding,
Tim Berners-Lee, Mark Davis, M.T. Carrasco Benitez, James Clark,
Tim Bray, Chris Wendt, Yaron Goland, Andrea Vine, Misha Wolf,
Leslie Daigle, Ted Hardie, Bill Fenner, Margaret Wasserman,
Russ Housley, Makoto MURATA, Steven Atkin, Ryan Stansifer,
Tex Texin, Graham Klyne, Bjoern Hoehrmann, Chris Lilley, Ian Jacobs,
Adam Costello, Dan Oscarson, Elliotte Rusty Harold, Mike J. Brown,
Roy Badami, Jonathan Rosenne, Asmus Freytag, Simon Josefsson,
Carlos Viegas Damasio, Chris Haynes, Walter Underwood, 그리고 많은
다른 분들께 깊이 감사드린다.
이 문서는 World Wide Web Consortium (W3C)의 Internationalization
Working Group (I18N WG)의 산물이다. W3C I18N Working Group과
Interest Group의 구성원들에게 그들의 기여와 [CharMod]에 대한
작업에 감사드린다. 또한 IRI를 채택한 여러 다른 W3C Working Group의
구성원들과, 검토를 해 준 Montreal IAB Workshop on Internationalization
and Localization의 구성원들에게도 감사드린다.
Duerst & Suignard Standards Track [Page 39]
RFC 3987 Internationalized Resource Identifiers January 2005
10. 참고 문헌
10.1. 규범 참고 문헌
[ASCII] American National Standards Institute, "Coded
Character Set -- 7-bit American Standard Code for
Information Interchange", ANSI X3.4, 1986.
[ISO10646] International Organization for Standardization,
"ISO/IEC 10646:2003: Information Technology -
Universal Multiple-Octet Coded Character Set (UCS)",
ISO Standard 10646, December 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
[UNI9] Davis, M., "The Bidirectional Algorithm", Unicode
Standard Annex #9, March 2004,
<http://www.unicode.org/reports/tr9/tr9-13.html>.
[UNIV4] The Unicode Consortium, "The Unicode Standard, Version
4.0.1, defined by: The Unicode Standard, Version 4.0
(Reading, MA, Addison-Wesley, 2003. ISBN
0-321-18578-1), as amended by Unicode 4.0.1
(http://www.unicode.org/versions/Unicode4.0.1/)",
March 2004.
Duerst & Suignard Standards Track [Page 40]
RFC 3987 Internationalized Resource Identifiers January 2005
[UTR15] Davis, M. and M. Duerst, "Unicode Normalization
Forms", Unicode Standard Annex #15, April 2003,
<http://www.unicode.org/unicode/reports/
tr15/tr15-23.html>.
10.2. 정보 제공 참고 문헌
[BidiEx] "Examples of bidirectional IRIs",
<http://www.w3.org/International/iri-edit/
BidiExamples>.
[CharMod] Duerst, M., Yergeau, F., Ishida, R., Wolf, M., and T.
Texin, "Character Model for the World Wide Web:
Resource Identifiers", World Wide Web Consortium
Candidate Recommendation, November 2004,
<http://www.w3.org/TR/charmod-resid>.
[Duerst97] Duerst, M., "The Properties and Promises of UTF-8",
Proc. 11th International Unicode Conference, San Jose
, September 1997,
<http://www.ifi.unizh.ch/mml/mduerst/papers/
PDF/IUC11-UTF-8.pdf>.
[Gettys] Gettys, J., "URI Model Consequences",
<http://www.w3.org/DesignIssues/ModelConsequences>.
[HTML4] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium
Recommendation, December 1999,
<http://www.w3.org/TR/html401/appendix/
notes.html#h-B.2>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,
Atkinson, R., Crispin, M., and P. Svanberg, "The
Report of the IAB Character Set Workshop held 29
February - 1 March, 1996", RFC 2130, April 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September
1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
Duerst & Suignard Standards Track [Page 41]
RFC 3987 Internationalized Resource Identifiers January 2005
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The
mailto URL scheme", RFC 2368, July 1998.
[RFC2384] Gellens, R., "POP URL Scheme", RFC 2384, August 1998.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
August 1998.
[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.
[RFC2640] Curtin, B., "Internationalization of the File Transfer
Protocol", RFC 2640, July 1999.
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R.
Petke, "Guidelines for new URL Schemes", RFC 2718,
November 1999.
[UNIXML] Duerst, M. and A. Freytag, "Unicode in XML and other
Markup Languages", Unicode Technical Report #20, World
Wide Web Consortium Note, June 2003,
<http://www.w3.org/TR/unicode-xml/>.
[XLink] DeRose, S., Maler, E., and D. Orchard, "XML Linking
Language (XLink) Version 1.0", World Wide Web
Consortium Recommendation, June 2001,
<http://www.w3.org/TR/xlink/#link-locators>.
[XML1] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
and F. Yergeau, "Extensible Markup Language (XML) 1.0
(Third Edition)", World Wide Web Consortium
Recommendation, February 2004,
<http://www.w3.org/TR/REC-xml#sec-external-ent>.
[XMLNamespace] Bray, T., Hollander, D., and A. Layman, "Namespaces in
XML", World Wide Web Consortium Recommendation,
January 1999, <http://www.w3.org/TR/REC-xml-names>.
[XMLSchema] Biron, P. and A. Malhotra, "XML Schema Part 2:
Datatypes", World Wide Web Consortium Recommendation,
May 2001, <http://www.w3.org/TR/xmlschema-2/#anyURI>.
Duerst & Suignard Standards Track [Page 42]
RFC 3987 Internationalized Resource Identifiers January 2005
[XPointer] Grosso, P., Maler, E., Marsh, J. and N. Walsh,
"XPointer Framework", World Wide Web Consortium
Recommendation, March 2003,
<http://www.w3.org/TR/xptr-framework/#escaping>.
Duerst & Suignard Standards Track [Page 43]
RFC 3987 Internationalized Resource Identifiers January 2005
Appendix A. 설계 대안
이 절은 주요 설계 대안과 그것들이 선택되지 않은 이유를 간략히
요약한다.
Appendix A.1. 새로운 스킴
새로운 scheme(예: httpi:, ftpi:, ...)이나 새로운 metascheme(예:
i:, URI/IRI 접두사 i:http:, i:ftp: 등을 유도)을 도입하는 것은
IRI-to-URI 변환을 scheme dependent하게 만들거나, IRI-to-URI
변환에서 생긴 percent-encoding과 legacy character encoding에서
생긴 percent-encoding을 구별하기 위해 제안되었다.
URI와 true IRI(즉 비ASCII 문자를 포함하는 IRI)를 구별하기 위해
새로운 scheme은 필요하지 않다. percent-encoding의 출처를 감지할 수
있는 이점은 미미하다. UTF-8은 매우 높은 신뢰도로 감지될 수 있기
때문이다. 새로운 scheme을 배포하는 것은 극히 어렵기 때문에, IRI에
대해 새로운 scheme을 요구하지 않으면 IRI 배포가 훨씬 쉬워진다.
변환을 scheme dependent하게 만드는 것은 매우 바람직하지 않으며,
IRI를 위한 별도 scheme은 이를 조장할 것이다. IRI에서 URI로의
변환에 균일한 규약을 사용하면 IRI 구현이 실제 새로운 scheme의
도입과 직교적으로 이루어진다.
Appendix A.2. UTF-8 이외의 문자 인코딩
초기 단계에서 IRI가 URI로 변환될 때 UTF-7이 UTF-8의 대안으로
고려되었다. UTF-7은 percent-encoding을 필요로 하지 않았을 것이며
대부분의 경우 percent-encoded UTF-8보다 짧았을 것이다.
UTF-8을 사용하면 "+" 문자의 사용에 대한 이중 계층화와 과부하를
피할 수 있다. UTF-8은 US-ASCII와 완전히 호환되므로 IETF에 의해
권장되어 왔고, 널리 사용되고 있다.
UTF-7은 많이 사용된 적이 없으며 현재는 명확히 권장되지 않는다.
구현에 UTF-8에서 UTF-7로, 그리고 다시 그 반대로 변환할 것을
요구하는 것은 추가적인 구현 부담이 될 것이다.
Appendix A.3. 새로운 인코딩 규약
옥텟에 기반한 URI의 기존 percent-encoding convention을 사용하는
대신, 새로운 encoding convention을 만들자는 아이디어가 있었다.
예를 들어 "%u"를 사용하여 UCS code point를 도입하는 것이다.
Duerst & Suignard Standards Track [Page 44]
RFC 3987 Internationalized Resource Identifiers January 2005
기존의 옥텟 기반 percent-encoding 메커니즘을 사용하면 URI 구문
업그레이드가 필요하지 않으며, 대응하는 server upgrade도 필요하지
않다.
Appendix A.4. URI/IRI에서 문자 인코딩 표시
일부 제안은 e-mail과 Web page의 "charset" 매개변수와 유사하게,
URI 자체 안의 새로운 구문 규약으로 URI 또는 IRI에 사용된 문자
인코딩을 표시하자고 제안했다. 예를 들어
"http://www.example.org/ros[iso-8859-1]é"; 안의 대괄호 라벨은
뒤따르는 "é";가 iso-8859-1로 해석되어야 함을 나타냈다.
UTF-8만 배타적으로 사용한다면 URI 구문 업그레이드는 필요하지 않다.
이는 버스 옆면이나 냅킨 위에서도 모든 경우에 올바르게 복사되어야
하는 잠재적으로 여러 개의 라벨을 피하게 해 주며, 사용성 문제를
줄인다(그리고 지나치게 성가신 일을 피한다). UTF-8만 배타적으로
사용하면 transcoding 오류와 혼란도 줄어든다.
Authors' Addresses
Martin Duerst (Note: 가능하면 "Duerst"를 u-umlaut와 함께 작성하기
바란다. 예를 들어 XML과 HTML에서는 "Dürst"처럼
쓴다.)
World Wide Web Consortium
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81 466 49 1170
Fax: +81 466 49 1171
EMail: duerst@w3.org
URI: http://www.w3.org/People/D%C3%BCrst/
(Note: 이는 IRI의 percent-encoded 형식이다.)
Michel Suignard
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
U.S.A.
Phone: +1 425 882-8080
EMail: michelsu@microsoft.com
URI: http://www.suignard.com
Duerst & Suignard Standards Track [Page 45]
RFC 3987 Internationalized Resource Identifiers January 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
이 문서는 BCP 78에 포함된 권리, 라이선스 및 제한의 적용을 받으며,
그 안에 명시된 경우를 제외하고 저자들은 모든 권리를 보유한다.
이 문서와 여기에 포함된 정보는 "AS IS" 기준으로 제공되며,
CONTRIBUTOR, 그가 대표하거나 후원을 받는 조직(있는 경우),
INTERNET SOCIETY 및 INTERNET ENGINEERING TASK FORCE는 명시적이든
묵시적이든 모든 보증을 부인한다. 여기에는 여기에 포함된 정보의
사용이 어떤 권리도 침해하지 않는다는 보증 또는 상품성이나 특정
목적 적합성에 대한 묵시적 보증이 포함되지만 이에 한정되지 않는다.
Intellectual Property
IETF는 이 문서에 설명된 기술의 구현 또는 사용과 관련된 것으로
주장될 수 있는 Intellectual Property Rights 또는 기타 권리의
유효성이나 범위, 또는 그러한 권리에 따른 라이선스가 제공될 수
있는지 여부에 대해 어떤 입장도 취하지 않는다. 또한 그러한 권리를
식별하기 위해 독자적인 노력을 했다고 진술하지도 않는다. IETF
Documents의 권리와 관련된 IETF 절차에 대한 정보는 BCP 78 및
BCP 79에서 확인할 수 있다.
IETF Secretariat에 제출된 IPR disclosure의 사본과 제공될 라이선스에
대한 모든 보증, 또는 이 명세의 구현자나 사용자가 그러한 proprietary
rights를 사용하기 위해 일반 라이선스나 허가를 얻으려는 시도의
결과는 http://www.ietf.org/ipr의 IETF online IPR repository에서
얻을 수 있다.
IETF는 이 표준을 구현하는 데 필요할 수 있는 기술을 포괄할 수 있는
copyright, patent 또는 patent application, 또는 기타 proprietary
rights를 알고 있는 모든 이해관계자가 이를 IETF에 알려 주기를
요청한다. 해당 정보는 ietf-ipr@ietf.org의 IETF로 보내기 바란다.
Acknowledgement
RFC Editor 기능을 위한 자금은 현재 Internet Society가 제공한다.
Duerst & Suignard Standards Track [Page 46]