네트워크 워킹 그룹 T. Berners-Lee RFC(Request for Comments): 3986 W3C/MIT STD: 66 R. Fielding 갱신함: 1738 Day Software 폐기하고 대체함: 2732, 2396, 1808 L. Masinter 분류: 표준 트랙 Adobe Systems 2005년 1월 통합 자원 식별자(URI): 일반 구문 이 메모의 상태 이 문서는 인터넷 커뮤니티를 위한 인터넷 표준 트랙 프로토콜을 명세하며, 개선을 위한 논의와 제안을 요청합니다. 이 프로토콜의 표준화 단계 및 상태에 대해서는 "인터넷 공식 프로토콜 표준"(STD 1)의 최신판을 참조하십시오. 이 메모의 배포에는 제한이 없습니다. Copyright Notice Copyright (C) The Internet Society (2005). Berners-Lee 외 표준 트랙 [1페이지]
RFC 3986 URI 일반 구문 2005년 1월 목차 1. 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. URI 개요 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. 일반 구문 . . . . . . . . . . . . . . . . . . . 6 1.1.2. 예 . . . . . . . . . . . . . . . . . . . . . . 7 1.1.3. URI, URL 및 URN . . . . . . . . . . . . . . . 7 1.2. 설계 고려 사항 . . . . . . . . . . . . . . . . . . . . 8 1.2.1. 전사 . . . . . . . . . . . . . . . . . . . . . 8 1.2.2. 식별과 상호 작용의 분리 . . . . . . . . . . . 9 1.2.3. 계층적 식별자 . . . . . . . . . . . . . . . . 10 1.3. 구문 표기법 . . . . . . . . . . . . . . . . . . . . . 11 2. 문자 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1. 퍼센트 인코딩 . . . . . . . . . . . . . . . . . . . . 12 2.2. 예약 문자 . . . . . . . . . . . . . . . . . . . . . . 12 2.3. 비예약 문자 . . . . . . . . . . . . . . . . . . . . . 13 2.4. 인코딩 또는 디코딩 시점 . . . . . . . . . . . . . . 14 2.5. 식별 데이터 . . . . . . . . . . . . . . . . . . . . . 14 3. 구문 구성요소 . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. 스킴 . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. 권한 . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1. 사용자 정보 . . . . . . . . . . . . . . . . . 18 3.2.2. 호스트 . . . . . . . . . . . . . . . . . . . . 18 3.2.3. 포트 . . . . . . . . . . . . . . . . . . . . . 22 3.3. 경로 . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4. 쿼리 . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.5. 프래그먼트 . . . . . . . . . . . . . . . . . . . . . . 24 4. 사용 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. URI 참조 . . . . . . . . . . . . . . . . . . . . . . 25 4.2. 상대 참조 . . . . . . . . . . . . . . . . . . . . . . 26 4.3. 절대 URI . . . . . . . . . . . . . . . . . . . . . . 27 4.4. 동일 문서 참조 . . . . . . . . . . . . . . . . . . 27 4.5. 접미사 참조 . . . . . . . . . . . . . . . . . . . . . 27 5. 참조 해결 . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. 기준 URI 설정 . . . . . . . . . . . . . . . . . . . 28 5.1.1. 콘텐츠에 내장된 기준 URI . . . . . . . . . . 29 5.1.2. 캡슐화 엔터티의 기준 URI . . . . . . . . . . 29 5.1.3. 검색 URI의 기준 URI . . . . . . . . . . . . 30 5.1.4. 기본 기준 URI . . . . . . . . . . . . . . . . 30 5.2. 상대 해결 . . . . . . . . . . . . . . . . . . . . . 30 5.2.1. 기준 URI 사전 파싱 . . . . . . . . . . . . . 31 5.2.2. 참조 변환 . . . . . . . . . . . . . . . . . . 31 5.2.3. 경로 병합 . . . . . . . . . . . . . . . . . . 32 5.2.4. 점 세그먼트 제거 . . . . . . . . . . . . . . 33 5.3. 구성요소 재조합 . . . . . . . . . . . . . . . . . . 35 5.4. 참조 해결 예 . . . . . . . . . . . . . . . . . . . 35 5.4.1. 정상 예 . . . . . . . . . . . . . . . . . . . 36 5.4.2. 비정상 예 . . . . . . . . . . . . . . . . . . 36 Berners-Lee 외 표준 트랙 [2페이지]
RFC 3986 URI 일반 구문 2005년 1월 6. 정규화 및 비교 . . . . . . . . . . . . . . . . . . . . . . . 38 6.1. 동등성 . . . . . . . . . . . . . . . . . . . . . . . . 38 6.2. 비교 단계 . . . . . . . . . . . . . . . . . . . . . . 39 6.2.1. 단순 문자열 비교 . . . . . . . . . . . . . . . 39 6.2.2. 구문 기반 정규화 . . . . . . . . . . . . . . . 40 6.2.3. 스킴 기반 정규화 . . . . . . . . . . . . . . . 41 6.2.4. 프로토콜 기반 정규화 . . . . . . . . . . . . 42 7. 보안 고려 사항 . . . . . . . . . . . . . . . . . . . . . . 43 7.1. 신뢰성 및 일관성 . . . . . . . . . . . . . . . . . . 43 7.2. 악의적 구성 . . . . . . . . . . . . . . . . . . . . . 43 7.3. 백엔드 트랜스코딩 . . . . . . . . . . . . . . . . . . 44 7.4. 드문 IP 주소 형식 . . . . . . . . . . . . . . . . . 45 7.5. 민감한 정보 . . . . . . . . . . . . . . . . . . . . 45 7.6. 의미론적 공격 . . . . . . . . . . . . . . . . . . . . 45 8. IANA 고려 사항 . . . . . . . . . . . . . . . . . . . . . . 46 9. 감사의 말 . . . . . . . . . . . . . . . . . . . . . . . . . 46 10. 참고 문헌 . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.1. 규범적 참고 문헌 . . . . . . . . . . . . . . . . . . 46 10.2. 정보 제공용 참고 문헌 . . . . . . . . . . . . . . . 47 A. URI의 통합 ABNF . . . . . . . . . . . . . . . . . . . . . . 49 B. 정규 표현식을 사용한 URI 참조 파싱 . . . . . . . . . . 50 C. 문맥에서 URI 구분 . . . . . . . . . . . . . . . . . . . . 51 D. RFC 2396에서의 변경 사항 . . . . . . . . . . . . . . . . . . 53 D.1. 추가 사항 . . . . . . . . . . . . . . . . . . . . . . 53 D.2. 수정 사항 . . . . . . . . . . . . . . . . . . . . . . 53 색인 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 저자 주소 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 전체 저작권 고지 . . . . . . . . . . . . . . . . . . . . . . . . 61 Berners-Lee 외 표준 트랙 [3페이지]
RFC 3986 URI 일반 구문 2005년 1월 1. 소개 통합 자원 식별자(URI)는 자원을 식별하기 위한 간단하고 확장 가능한 수단을 제공합니다. 이 URI 구문 및 의미론 명세는 월드 와이드 웹 글로벌 정보 이니셔티브에서 도입된 개념에서 유래했으며, 이러한 식별자의 사용은 1990년부터 시작되었고 "WWW의 범용 자원 식별자" [RFC1630]에 설명되어 있습니다. 이 구문은 "인터넷 자원 위치 지정자에 대한 기능적 권고 사항" [RFC1736] 및 "통합 자원 이름에 대한 기능 요구 사항" [RFC1737]에 제시된 권고 사항을 충족하도록 설계되었습니다. 이 문서는 모든 URI에 대한 단일 일반 구문을 정의하기 위해 "통합 자원 위치 지정자" [RFC1738]와 "상대 통합 자원 위치 지정자" [RFC1808]를 통합한 [RFC2396]을 폐기하고 대체합니다. 또한 IPv6 주소 구문을 도입한 [RFC2732]를 폐기하고 대체합니다. 개별 URI 스킴의 특정 구문을 정의했던 RFC 1738의 일부는 제외하며, 해당 부분은 별도의 문서로 갱신됩니다. 새로운 URI 스킴 등록 절차는 [BCP35]에서 별도로 정의됩니다. 새로운 URI 스킴 설계자를 위한 조언은 [RFC2718]에서 확인할 수 있습니다. RFC 2396에서의 모든 중요한 변경 사항은 부록 D에 기록되어 있습니다. 이 명세는 [BCP19]에서 제공하는 정의에 따라 "문자" 및 "부호화 문자 집합"이라는 용어를 사용하며, [BCP19]에서 "charset"이라고 하는 것을 대신하여 "문자 인코딩"이라는 용어를 사용합니다. 1.1. URI 개요 URI는 다음과 같은 특성을 가집니다. 통합성 통합성은 여러 이점을 제공합니다. 자원에 접근하는 데 사용되는 메커니즘이 서로 다르더라도 서로 다른 유형의 자원 식별자를 동일한 문맥에서 사용할 수 있습니다. 서로 다른 유형의 자원 식별자 전반에서 공통 구문 규약을 일관된 의미로 해석할 수 있습니다. 기존 식별자가 사용되는 방식에 영향을 주지 않고 새로운 유형의 자원 식별자를 도입할 수 있습니다. 식별자를 여러 다른 문맥에서 재사용할 수 있으므로, 새로운 애플리케이션 또는 프로토콜에서 이미 존재하고 규모가 크며 널리 사용되는 자원 식별자 집합을 활용할 수 있습니다. Berners-Lee 외 표준 트랙 [4페이지]
RFC 3986 URI 일반 구문 2005년 1월 자원 이 명세는 무엇이 자원이 될 수 있는지 그 범위를 제한하지 않습니다. 대신 "자원"이라는 용어는 URI로 식별될 수 있는 모든 것을 일반적인 의미로 나타내는 데 사용됩니다. 익숙한 예로는 전자 문서, 이미지, 일관된 목적을 가진 정보의 출처(예: "오늘의 로스앤젤레스 날씨 보고서"), 서비스 (예: HTTP-to-SMS 게이트웨이), 기타 자원의 모음 등이 있습니다. 자원이 반드시 인터넷을 통해 접근 가능해야 하는 것은 아닙니다. 예를 들어 사람, 기업 및 도서관에 제본되어 있는 책도 자원이 될 수 있습니다. 마찬가지로 수학 방정식의 연산자와 피연산자, 관계의 유형 (예: "부모" 또는 "직원") 또는 숫자 값(예: 0, 1 및 무한대)과 같은 추상적 개념도 자원이 될 수 있습니다. 식별자 식별자는 식별 범위 내에서 식별 대상과 다른 모든 것을 구별하는 데 필요한 정보를 담고 있습니다. 여기서 "식별" 및 "식별하는"이라는 용어는 그 목적이 어떤 방식으로 달성되는지(예: 이름, 주소 또는 문맥)와 관계없이 하나의 자원을 다른 모든 자원과 구별한다는 의미입니다. 이러한 용어를 식별자가 참조 대상의 정체성을 정의하거나 그 자체에 담고 있다는 가정으로 오해해서는 안 됩니다. 일부 식별자에서는 그럴 수도 있지만 반드시 그런 것은 아닙니다. 또한 URI를 사용하는 시스템이 식별된 자원에 접근한다고 가정해서도 안 됩니다. 많은 경우 URI는 접근할 의도 없이 자원을 나타내는 데 사용됩니다. 마찬가지로 식별된 "하나의" 자원이 본질적으로 단일한 것이 아닐 수도 있습니다 (예: 자원이 이름이 지정된 집합이거나 시간에 따라 달라지는 매핑일 수 있습니다). URI는 제3절의 <URI>라는 구문 규칙에 일치하는 문자 시퀀스로 구성된 식별자입니다. URI는 별도로 정의된 확장 가능한 명명 스킴 집합(제3.1절)을 통해 자원을 통합적으로 식별할 수 있게 합니다. 이러한 식별이 어떻게 수행되고 할당되며 가능하게 되는지는 각 스킴 명세에 위임됩니다. 이 명세는 자원의 성격, 애플리케이션이 자원을 참조하려는 이유 또는 자원 식별을 위해 URI를 사용할 수 있는 시스템의 종류를 제한하지 않습니다. 이 명세는 URI가 시간이 지나도 동일한 자원을 계속 식별하도록 요구하지는 않지만, 이는 모든 URI 스킴의 일반적인 목표입니다. 그럼에도 이 Berners-Lee 외 표준 트랙 [5페이지]
RFC 3986 URI 일반 구문 2005년 1월 명세의 어떤 내용도 애플리케이션이 특정 유형의 자원이나 해당 애플리케이션이 원하는 특성을 유지하는 URI의 하위 집합으로 자신을 제한하는 것을 막지 않습니다. URI는 전역 범위를 가지며 문맥과 관계없이 일관되게 해석되지만, 그 해석 결과는 최종 사용자의 문맥과 관련될 수 있습니다. 예를 들어 "http://localhost/"는 "localhost"에 해당하는 네트워크 인터페이스가 최종 사용자마다 다를 수 있더라도 해당 참조를 사용하는 모든 사용자에게 동일하게 해석됩니다. 즉, 해석은 접근과 독립적입니다. 그러나 해당 참조를 기반으로 수행되는 동작은 최종 사용자의 문맥과 관련하여 이루어집니다. 따라서 전역적으로 고유한 대상을 참조하려는 동작은 그 자원을 다른 모든 대상과 구별하는 URI를 사용해야 합니다. 최종 사용자의 로컬 문맥과 관련하여 식별하는 URI는 온라인 도움말 설명서가 최종 사용자의 파일 시스템에 있는 파일(예: "file:///etc/hosts")을 참조하는 경우처럼 문맥 자체가 자원을 정의하는 측면일 때만 사용해야 합니다. 1.1.1. 일반 구문 각 URI는 제3.1절에 정의된 스킴 이름으로 시작하며, 해당 스킴 내에서 식별자를 할당하는 명세를 참조합니다. 따라서 URI 구문은 연합되고 확장 가능한 명명 시스템이며, 각 스킴의 명세는 해당 스킴을 사용하는 식별자의 구문 및 의미론을 추가로 제한할 수 있습니다. 이 명세는 모든 URI 스킴에 필요하거나 여러 URI 스킴에 공통적인 URI 구문 요소를 정의합니다. 따라서 URI 참조를 스킴과 독립적으로 파싱하는 메커니즘을 구현하는 데 필요한 구문 및 의미론을 정의하며, 이를 통해 URI의 스킴별 처리를 스킴별 의미론이 필요해질 때까지 연기할 수 있습니다. 마찬가지로 URI 참조를 사용하는 프로토콜과 데이터 형식은 아직 정의되지 않은 스킴을 포함한 모든 URI에 허용되는 구문의 범위를 정의하기 위해 이 명세를 참조할 수 있습니다. 이를 통해 식별 스킴의 발전과 URI를 사용하는 프로토콜, 데이터 형식 및 구현의 발전을 서로 분리할 수 있습니다. 일반 URI 구문 파서는 모든 URI 참조를 주요 구성요소로 파싱할 수 있습니다. 스킴이 결정되면 구성요소에 대해 스킴별 추가 파싱을 수행할 수 있습니다. 다시 말해 URI 일반 구문은 모든 URI 스킴 구문의 상위 집합입니다. Berners-Lee 외 표준 트랙 [6페이지]
RFC 3986 URI 일반 구문 2005년 1월 1.1.2. 예 다음 URI 예는 여러 URI 스킴과 공통 구문 구성요소의 다양한 형태를 보여 줍니다. ftp://ftp.is.co.za/rfc/rfc1808.txt http://www.ietf.org/rfc/rfc2396.txt ldap://[2001:db8::7]/c=GB?objectClass?one mailto:John.Doe@example.com news:comp.infosystems.www.servers.unix tel:+1-816-555-1212 telnet://192.0.2.16:80/ urn:oasis:names:specification:docbook:dtd:xml:4.1.2 1.1.3. URI, URL 및 URN URI는 위치 지정자, 이름 또는 둘 다로 더 세분화할 수 있습니다. "통합 자원 위치 지정자"(URL)라는 용어는 자원을 식별하는 것에 더해 자원의 주요 접근 메커니즘 (예: 네트워크상의 "위치")을 설명하여 해당 자원을 찾을 수 있는 수단을 제공하는 URI의 하위 집합을 나타냅니다. "통합 자원 이름"(URN)이라는 용어는 역사적으로 "urn" 스킴 [RFC2141] 아래의 URI와, 자원이 더 이상 존재하지 않거나 이용할 수 없게 된 후에도 전역적으로 고유하고 영속적으로 유지되어야 하는 URI, 그리고 이름의 특성을 가진 기타 모든 URI를 지칭하는 데 사용되었습니다. 개별 스킴을 반드시 "이름" 또는 "위치 지정자" 중 하나로만 분류할 필요는 없습니다. 특정 스킴에 속한 URI 인스턴스는 이름, 위치 지정자 또는 둘 다의 특성을 가질 수 있으며, 이는 스킴 자체의 특성보다는 명명 기관이 식별자를 할당할 때의 지속성과 관리 방식에 따라 달라지는 경우가 많습니다. 향후 명세 및 관련 문서에서는 더 제한적인 "URL" 및 "URN" [RFC3305]이라는 용어보다 일반적인 "URI"라는 용어를 사용하는 것이 좋습니다. Berners-Lee 외 표준 트랙 [7페이지]
RFC 3986 URI 일반 구문 2005년 1월 1.2. 설계 고려 사항 1.2.1. 전사 URI 구문은 전 세계적으로 전사할 수 있도록 하는 것을 주요 고려 사항 중 하나로 두고 설계되었습니다. URI는 매우 제한된 집합의 문자, 즉 기본 라틴 알파벳의 문자, 숫자 및 몇 개의 특수 문자로 이루어진 시퀀스입니다. URI는 다양한 방식으로 표현될 수 있습니다. 예를 들어 종이에 잉크로 쓰거나, 화면의 픽셀 또는 문자 인코딩 옥텟의 시퀀스로 표현할 수 있습니다. URI의 해석은 사용된 문자에만 의존하며, 해당 문자가 네트워크 프로토콜에서 어떻게 표현되는지에는 의존하지 않습니다. 전사의 목표는 간단한 시나리오로 설명할 수 있습니다. 국제 학회에 참석한 두 동료 Sam과 Kim이 술집에 앉아 연구 아이디어를 주고받는 상황을 상상해 보십시오. Sam은 Kim에게 추가 정보를 얻을 수 있는 위치를 묻고, Kim은 연구 사이트의 URI를 냅킨에 적습니다. 집으로 돌아온 Sam은 냅킨을 꺼내 URI를 컴퓨터에 입력하고, 컴퓨터는 Kim이 가리킨 정보를 가져옵니다. 이 시나리오에서 드러나는 몇 가지 설계 고려 사항은 다음과 같습니다. o URI는 문자 시퀀스이며 항상 옥텟 시퀀스로 표현되는 것은 아닙니다. o URI는 네트워크가 아닌 출처에서 전사될 수 있으므로 여러 언어와 로케일의 키보드(및 관련 입력 장치)가 부과하는 제약 내에서 컴퓨터에 입력할 가능성이 가장 높은 문자로 구성되어야 합니다. o URI는 사람이 기억해야 하는 경우가 많으며, 의미 있거나 익숙한 구성요소로 이루어져 있을 때 사람이 URI를 더 쉽게 기억할 수 있습니다. 이러한 설계 고려 사항이 항상 일치하는 것은 아닙니다. 예를 들어 URI 구성요소에 가장 의미 있는 이름에는 일부 시스템에서 입력할 수 없는 문자가 필요한 경우가 많습니다. 자원 식별자를 한 매체에서 다른 매체로 전사할 수 있는 능력은 URI가 가장 의미 있는 구성요소로 이루어지는 것보다 더 중요하게 고려되었습니다. 로컬 또는 지역적 문맥에서 기술이 발전함에 따라 사용자는 더 넓은 범위의 문자를 사용할 수 있으면 이점을 얻을 수 있습니다. 이러한 사용은 이 명세에서 정의하지 않습니다. 이 Berners-Lee 외 표준 트랙 [8페이지]
RFC 3986 URI 일반 구문 2005년 1월 표현이 스킴 또는 URI가 참조되는 프로토콜 요소에서 허용되는 경우, 퍼센트 인코딩된 옥텟(제2.1절)을 URI 내에서 사용하여 US-ASCII 부호화 문자 집합의 범위를 벗어나는 문자를 표현할 수 있습니다. 그러한 정의에서는 해당 문자를 URI용으로 퍼센트 인코딩하기 전에 옥텟으로 매핑하는 데 사용하는 문자 인코딩을 지정하는 것이 좋습니다. 1.2.2. 식별과 상호 작용의 분리 URI에 대한 일반적인 오해는 접근 가능한 자원을 참조하는 데만 사용된다는 것입니다. URI 자체는 식별만을 제공하며, 자원에 대한 접근은 URI의 존재만으로 보장되거나 암시되지 않습니다. 대신 URI 참조와 관련된 모든 동작은 해당 URI가 나타나는 프로토콜 요소, 데이터 형식 속성 또는 자연어 텍스트에 의해 정의됩니다. URI가 주어지면 시스템은 자원에 대해 "접근", "갱신", "대체" 또는 "속성 찾기"와 같은 말로 표현할 수 있는 다양한 동작을 수행하려 할 수 있습니다. 이러한 동작은 URI를 사용하는 프로토콜에 의해 정의되며 이 명세에서 정의하지 않습니다. 다만 URI에 대한 일반적인 동작을 설명하기 위해 몇 가지 일반 용어를 사용합니다. URI "해결"은 URI를 역참조하는 데 필요한 접근 메커니즘과 적절한 매개변수를 결정하는 과정이며, 이 해결에는 여러 차례의 반복이 필요할 수 있습니다. 해당 접근 메커니즘을 사용하여 URI의 자원에 동작을 수행하는 것을 URI를 "역참조"한다고 합니다. 정보 검색 시스템에서 정보의 출처를 식별하기 위해 URI를 사용할 때 URI 역참조의 가장 일반적인 형태는 "검색"입니다. 즉, URI를 사용하여 연관된 자원의 표현을 가져오는 것입니다. "표현"은 옥텟 시퀀스와 해당 옥텟을 설명하는 표현 메타데이터로 구성되며, 표현이 생성된 시점의 자원 상태 기록을 이룹니다. 검색은 URI를 캐시 키로 사용하여 로컬에 캐시된 표현을 확인하고, 적절한 접근 메커니즘(있는 경우)을 결정하기 위해 URI를 해결하고, 검색 동작을 적용하기 위해 URI를 역참조하는 과정을 포함할 수 있습니다. 검색에 사용하는 프로토콜에 따라 자원에 관한 추가 정보(자원 메타데이터)와 다른 자원과의 관계가 제공될 수 있습니다. 정보 검색 시스템의 URI 참조는 늦은 바인딩을 위해 설계됩니다. 즉, 접근 결과는 일반적으로 접근 시점에 결정되며 시간 또는 상호 작용의 다른 측면에 따라 달라질 수 있습니다. 이러한 참조는 미래에 사용하기 위해 생성됩니다. 식별되는 것은 과거에 얻은 특정 결과가 아니라 향후 결과에서도 참일 것으로 예상되는 어떤 특성입니다. 이러한 경우 URI가 참조하는 자원은 실제로 시간에 따라 관찰되는 Berners-Lee 외 표준 트랙 [9페이지]
RFC 3986 URI 일반 구문 2005년 1월 특성의 동일성이며, 이는 자원 제공자가 추가로 작성한 의견이나 주장에 의해 더 명확해질 수 있습니다. 많은 URI 스킴이 프로토콜 이름을 따서 명명되어 있지만, 그렇다고 이러한 URI를 사용하면 이름이 지정된 프로토콜을 통해 자원에 접근하게 된다는 의미는 아닙니다. URI는 흔히 단순히 식별 목적으로 사용됩니다. URI를 사용하여 자원의 표현을 가져오는 경우에도 그 접근은 스킴 이름과 연관된 프로토콜과 독립적인 게이트웨이, 프록시, 캐시 및 이름 해결 서비스를 통해 이루어질 수 있습니다. 일부 URI를 해결하려면 둘 이상의 프로토콜을 사용해야 할 수도 있습니다(예: 로컬 캐시에서 표현을 찾지 못하면 "http" URI의 원본 서버에 접근할 때 일반적으로 DNS와 HTTP가 모두 사용됩니다). 1.2.3. 계층적 식별자 URI 구문은 계층적으로 구성되며, 구성요소는 왼쪽에서 오른쪽으로 중요도가 감소하는 순서로 나열됩니다. 일부 URI 스킴에서는 표시되는 계층이 스킴 자체로 제한됩니다. 스킴 구성요소 구분자(":") 뒤의 모든 내용은 URI 처리에 대해 불투명한 것으로 간주됩니다. 다른 URI 스킴은 일반 파싱 알고리즘에 계층을 명시적이고 가시적으로 나타냅니다. 일반 구문은 슬래시("/"), 물음표("?") 및 번호 기호("#") 문자를 사용하여 일반 파서가 식별자를 계층적으로 해석할 때 중요한 구성요소를 구분합니다. 익숙한 구문을 일관되게 사용하여 이러한 식별자의 가독성을 높이는 것 외에도, 명명 스킴 전반에서 계층을 이렇게 통일된 방식으로 표현하면 해당 계층에 상대적인 스킴 독립적 참조를 만들 수 있습니다. 공통 목적을 위해 문서의 그룹 또는 "트리"가 구성되는 경우가 많으며, 이러한 문서의 URI 참조 대부분은 트리 외부가 아니라 트리 내부의 자원을 가리킵니다. 마찬가지로 특정 사이트에 위치한 문서는 원격 사이트의 자원보다 같은 사이트의 다른 자원을 참조할 가능성이 훨씬 높습니다. URI의 상대 참조를 사용하면 문서 트리가 위치 및 접근 스킴에서 부분적으로 독립적일 수 있습니다. 예를 들어 하나의 하이퍼텍스트 문서 집합이 서로를 상대 참조로 가리키는 경우 "file", "http" 및 "ftp" 스킴 각각을 통해 동시에 접근하고 탐색할 수 있습니다. 또한 이러한 문서 트리는 상대 참조를 변경하지 않고 전체를 이동할 수 있습니다. 상대 참조(제4.2절)는 참조 문맥과 대상 URI 사이의 계층적 이름 공간 내 차이를 설명하여 자원을 참조합니다. 제5절에 제시된 참조 해결 알고리즘은 이러한 참조가 대상 URI로 Berners-Lee 외 표준 트랙 [10페이지]
RFC 3986 URI 일반 구문 2005년 1월 변환되는 방법을 정의합니다. 상대 참조는 계층적 URI의 문맥 내에서만 사용할 수 있으므로 새로운 URI 스킴의 설계자는 해당 스킴에서 상대 참조를 금지할 설득력 있는 이유가 없는 한 일반 구문의 계층적 구성요소와 일치하는 구문을 사용하는 것이 좋습니다. 참고: 이전 명세에서는 URI에 대한 상대 참조를 나타내기 위해 "부분 URI" 및 "상대 URI"라는 용어를 사용했습니다. 일부 독자가 이러한 용어를 URI를 참조하는 방법이 아니라 상대 URI가 URI의 하위 집합이라는 뜻으로 오해했으므로, 이 명세에서는 이를 단순히 상대 참조라고 합니다. 모든 URI 참조는 사용 시 일반 구문 파서에 의해 파싱됩니다. 그러나 계층 처리는 하나 이상의 점 세그먼트 (제3.3절에 설명된 "." 또는 ".."의 완전한 경로 세그먼트)를 포함하지 않는 한 참조에 사용된 절대 URI에 아무런 영향을 주지 않으므로, URI 스킴 명세는 슬래시 문자, 물음표 문자 및 "scheme:."과 "scheme:.." URI의 사용을 금지하여 불투명 식별자를 정의할 수 있습니다. 1.3. 구문 표기법 이 명세는 [RFC2234]의 Augmented Backus-Naur Form(ABNF) 표기법을 사용하며, 해당 명세에서 정의하는 다음 핵심 ABNF 구문 규칙을 포함합니다. ALPHA(문자), CR(캐리지 리턴), DIGIT(10진수 숫자), DQUOTE(큰따옴표), HEXDIG(16진수 숫자), LF(줄 바꿈) 및 SP(공백). 전체 URI 구문은 부록 A에 모아 두었습니다. 2. 문자 URI 구문은 자원을 식별하기 위한 것으로 추정되는 데이터를 문자 시퀀스로 인코딩하는 방법을 제공합니다. URI 문자는 다시 전송 또는 표시를 위해 옥텟으로 인코딩되는 경우가 많습니다. 이 명세는 URI 문자와 해당 문자를 저장하거나 전송하는 데 사용되는 옥텟 사이를 매핑하기 위한 특정 문자 인코딩을 요구하지 않습니다. URI가 프로토콜 요소에 나타날 때 문자 인코딩은 해당 프로토콜에 의해 정의되며, 그러한 정의가 없으면 URI는 주변 텍스트와 동일한 문자 인코딩을 사용한다고 가정합니다. ABNF 표기법은 종단 값을 US-ASCII 부호화 문자 집합 [ASCII]을 기반으로 하는 0 이상의 정수(코드 포인트)로 정의합니다. URI는 문자 시퀀스이므로 URI 구문을 이해하려면 그 관계를 반대로 적용해야 합니다. 따라서 Berners-Lee 외 표준 트랙 [11페이지]
RFC 3986 URI 일반 구문 2005년 1월 ABNF에서 사용하는 정수 값은 구문 규칙을 완성하기 위해 US-ASCII를 통해 해당 문자로 다시 매핑되어야 합니다. URI는 숫자, 문자 및 몇 개의 그래픽 기호로 이루어진 제한된 문자 집합으로 구성됩니다. 이러한 문자 중 예약된 하위 집합은 URI 내부의 구문 구성요소를 구분하는 데 사용될 수 있으며, 비예약 집합 및 구분자로 작동하지 않는 예약 문자를 포함한 나머지 문자는 각 구성요소의 식별 데이터를 정의합니다. 2.1. 퍼센트 인코딩 어떤 옥텟에 해당하는 문자가 허용된 집합 밖에 있거나 구성요소의 구분자 또는 구성요소 내부의 구분자로 사용되는 경우, 구성요소에서 데이터 옥텟을 표현하기 위해 퍼센트 인코딩 메커니즘을 사용합니다. 퍼센트 인코딩된 옥텟은 퍼센트 문자 "%" 뒤에 해당 옥텟의 숫자 값을 나타내는 두 개의 16진수 숫자를 붙인 세 문자 묶음으로 인코딩됩니다. 예를 들어 "%20"은 이진 옥텟 "00100000"(ABNF: %x20)의 퍼센트 인코딩이며, US-ASCII에서는 공백 문자(SP)에 해당합니다. 제2.4절에서는 퍼센트 인코딩 및 디코딩을 적용하는 시점을 설명합니다. pct-encoded = "%" HEXDIG HEXDIG 대문자 16진수 숫자 'A'부터 'F'는 각각 소문자 'a'부터 'f'와 동등합니다. 두 URI가 퍼센트 인코딩된 옥텟에 사용하는 16진수 숫자의 대소문자만 다르다면 이들은 동등합니다. 일관성을 위해 URI 생성자와 정규화기는 모든 퍼센트 인코딩에 대문자 16진수 숫자를 사용하는 것이 좋습니다. 2.2. 예약 문자 URI에는 "reserved" 집합의 문자로 구분되는 구성요소 및 하위 구성요소가 포함됩니다. 이러한 문자를 "예약" 문자라고 하는 이유는 일반 구문, 각 스킴별 구문 또는 URI 역참조 알고리즘의 구현별 구문에서 구분자로 정의될 수도 있고 정의되지 않을 수도 있기 때문입니다. URI 구성요소의 데이터가 예약 문자의 구분자 역할과 충돌한다면, 충돌하는 데이터는 URI가 만들어지기 전에 퍼센트 인코딩되어야 합니다. Berners-Lee 외 표준 트랙 [12페이지]
RFC 3986 URI 일반 구문 2005년 1월 reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" 예약 문자의 목적은 URI 내의 다른 데이터와 구별할 수 있는 구분 문자 집합을 제공하는 것입니다. 예약 문자를 해당 퍼센트 인코딩 옥텟으로 바꾸는 것만 다른 URI는 동등하지 않습니다. 예약 문자를 퍼센트 인코딩하거나 예약 문자에 해당하는 퍼센트 인코딩 옥텟을 디코딩하면 대부분의 애플리케이션에서 URI가 해석되는 방식이 달라집니다. 따라서 예약 집합의 문자는 정규화로부터 보호되며, 스킴별 및 생성자별 알고리즘이 URI 내의 데이터 하위 구성요소를 구분하는 데 안전하게 사용할 수 있습니다. 예약 문자 중 일부(gen-delims)는 제3절에 설명된 일반 URI 구성요소의 구분자로 사용됩니다. 구성요소의 ABNF 구문 규칙은 reserved 또는 gen-delims 규칙 이름을 직접 사용하지 않습니다. 대신 각 구문 규칙은 해당 구성요소에서 허용되는 문자(즉, 구성요소를 구분하지 않는 문자)를 나열하며, 그 문자 중 예약 집합에도 속하는 문자는 구성요소 내부에서 하위 구성요소 구분자로 사용하도록 "예약"됩니다. 이 명세에서는 가장 일반적인 하위 구성요소만 정의합니다. 다른 하위 구성요소는 해당 구성요소 내에서 허용되는 예약 집합의 문자로 구분된다는 조건으로 URI 스킴 명세 또는 URI 역참조 알고리즘의 구현별 구문에서 정의할 수 있습니다. URI를 생성하는 애플리케이션은 예약 집합의 문자에 해당하는 데이터 옥텟을 퍼센트 인코딩하는 것이 좋습니다. 단, URI 스킴이 해당 구성요소에서 이러한 문자를 데이터 표현용으로 특별히 허용한 경우는 예외입니다. 예약 문자가 URI 구성요소에서 발견되고 그 문자에 대해 알려진 구분 역할이 없다면, 해당 문자의 US-ASCII 인코딩에 대응하는 데이터 옥텟을 나타내는 것으로 해석해야 합니다. 2.3. 비예약 문자 URI에서 허용되지만 예약된 목적을 가지지 않는 문자를 비예약 문자라고 합니다. 여기에는 대문자와 소문자, 10진수 숫자, 하이픈, 마침표, 밑줄 및 물결표가 포함됩니다. unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" Berners-Lee 외 표준 트랙 [13페이지]
RFC 3986 URI 일반 구문 2005년 1월 비예약 문자를 해당 퍼센트 인코딩된 US-ASCII 옥텟으로 대체한 것만 다른 URI는 동등합니다. 즉, 동일한 자원을 식별합니다. 그러나 URI 비교 구현은 비교 전에 항상 정규화를 수행하는 것은 아닙니다(제 6절 참조). 일관성을 위해 ALPHA(%41-%5A 및 %61-%7A), DIGIT(%30-%39), 하이픈(%2D), 마침표(%2E), 밑줄(%5F) 또는 물결표(%7E) 범위의 퍼센트 인코딩된 옥텟은 URI 생성자가 만들지 않는 것이 좋으며, URI에서 발견되면 URI 정규화기가 해당 비예약 문자로 디코딩하는 것이 좋습니다. 2.4. 인코딩 또는 디코딩 시점 정상적인 상황에서 URI 내부의 옥텟이 퍼센트 인코딩되는 유일한 시점은 구성요소 부분에서 URI를 생성하는 과정입니다. 이때 구현은 예약 문자 중 어떤 것을 하위 구성요소 구분자로 사용하고 어떤 것을 데이터로 안전하게 사용할 수 있는지 결정합니다. 생성된 이후 URI는 항상 퍼센트 인코딩된 형태로 존재합니다. URI를 역참조할 때 스킴별 역참조 과정에 중요한 구성요소 및 하위 구성요소(있는 경우)는 그 내부의 퍼센트 인코딩된 옥텟을 안전하게 디코딩하기 전에 반드시 파싱하고 분리해야 합니다. 그렇지 않으면 데이터가 구성요소 구분자로 오인될 수 있습니다. 유일한 예외는 비예약 집합의 문자에 해당하는 퍼센트 인코딩된 옥텟이며, 이는 언제든지 디코딩할 수 있습니다. 예를 들어 물결표("~") 문자에 해당하는 옥텟은 이전 URI 처리 구현에서 "%7E"로 인코딩되는 경우가 많으며, "%7E"를 "~"로 대체해도 해석은 바뀌지 않습니다. 퍼센트("%") 문자는 퍼센트 인코딩된 옥텟의 표시자로 사용되므로 이 옥텟을 URI 내부의 데이터로 사용하려면 "%25"로 퍼센트 인코딩해야 합니다. 구현은 동일한 문자열을 두 번 이상 퍼센트 인코딩하거나 디코딩해서는 안 됩니다. 이미 디코딩된 문자열을 다시 디코딩하면 퍼센트 데이터 옥텟을 퍼센트 인코딩의 시작으로 잘못 해석할 수 있으며, 이미 퍼센트 인코딩된 문자열을 다시 퍼센트 인코딩하는 경우에는 그 반대의 문제가 발생할 수 있습니다. 2.5. 식별 데이터 URI 문자는 각 URI 구성요소에 식별 데이터를 제공하며, 시스템 간 식별을 위한 외부 인터페이스 역할을 합니다. URI 생성 인터페이스의 존재 여부와 특성은 해당 URI를 사용하는 클라이언트에게 숨겨져 있으므로 이 명세에서 정의하는 상호 운용성 요구 사항의 범위를 벗어나지만, URI 문자 문제를 해석할 때 혼란과 오류가 자주 발생하는 원인이 됩니다. 구현자는 URI의 생성 및 전송에 여러 문자 인코딩이 Berners-Lee 외 표준 트랙 [14페이지]
RFC 3986 URI 일반 구문 2005년 1월 관련된다는 점을 알아야 합니다. 여기에는 로컬 이름 및 데이터 인코딩, 공개 인터페이스 인코딩, URI 문자 인코딩, 데이터 형식 인코딩 및 프로토콜 인코딩이 포함됩니다. 파일 시스템 이름과 같은 로컬 이름은 로컬 문자 인코딩으로 저장됩니다. URI를 생성하는 애플리케이션(예: 원본 서버)은 일반적으로 의미 있는 이름을 생성하는 기반으로 로컬 인코딩을 사용합니다. URI 생성자는 로컬 인코딩을 공개 인터페이스에 적합한 인코딩으로 변환한 다음, 공개 인터페이스 인코딩을 제한된 URI 문자 집합 (예약 문자, 비예약 문자 및 퍼센트 인코딩)으로 변환합니다. 그런 다음 해당 문자는 데이터 형식(예: 문서 문자 집합) 내부에서 참조로 사용되도록 옥텟으로 인코딩되고, 이러한 데이터 형식은 이후 인터넷 프로토콜을 통한 전송을 위해 인코딩되는 경우가 많습니다. 대부분의 시스템에서 URI 구성요소에 나타나는 비예약 문자는 해당 문자의 US-ASCII 인코딩에 대응하는 데이터 옥텟을 나타내는 것으로 해석됩니다. URI 소비자는 문자 "X"가 옥텟 "01011000"에 해당한다고 가정하며, 이 가정이 틀리더라도 그렇게 가정하는 데 해는 없습니다. 내부적으로 EBCDIC과 같은 다른 문자 인코딩 형태로 식별자를 제공하는 시스템은 일반적으로 내부 인터페이스에서 텍스트 식별자를 UTF-8 [STD63](또는 US-ASCII 문자 인코딩의 다른 상위 집합)로 문자 변환하여, 원래 옥텟을 단순히 퍼센트 인코딩했을 때보다 더 의미 있는 식별자를 제공합니다. 예를 들어 EBCDIC 기반 파일 시스템을 사용해 로컬에 저장된 데이터를 HTTP 서버를 통해 인터넷의 클라이언트에게 제공하는 정보 서비스를 생각해 보십시오. 작성자가 해당 파일 시스템에 "Laguna Beach"라는 이름의 파일을 만들면 해당 자원에 대응하는 "http" URI에는 의미 있는 문자열 "Laguna%20Beach"가 포함될 것으로 예상됩니다. 그러나 서버가 지나치게 단순한 원시 옥텟 매핑을 사용하여 URI를 생성한다면 결과는 "%D3%81%87%A4%95%81@%C2%85%81%83%88"을 포함하는 URI가 됩니다. 내부 트랜스코딩 인터페이스는 URI를 생성하기 전에 로컬 이름을 US-ASCII의 상위 집합으로 트랜스코딩하여 이 문제를 해결합니다. 당연히 이러한 인터페이스에서 수신 URI를 올바르게 해석하려면 역방향 트랜스코딩을 적용하여 로컬 이름을 얻기 전에 퍼센트 인코딩된 옥텟을 디코딩해야 합니다 (예: "%20"을 SP로). 경우에 따라 URI 구성요소와 그것이 표현하도록 만들어진 식별 데이터 사이의 내부 인터페이스는 문자 인코딩 변환보다 훨씬 직접적이지 않을 수 있습니다. 예를 들어 URI의 일부는 비ASCII 데이터에 대한 쿼리 또는 숫자로 된 Berners-Lee 외 표준 트랙 [15페이지]
RFC 3986 URI 일반 구문 2005년 1월 지도상의 좌표를 반영할 수 있습니다. 마찬가지로 URI 스킴은 구성요소를 형성하고 URI를 생성하기 전에 적용되는 추가 인코딩 요구 사항을 가진 구성요소를 정의할 수 있습니다. 새로운 URI 스킴이 범용 문자 집합 [UCS]의 문자로 구성된 텍스트 데이터를 나타내는 구성요소를 정의하는 경우, 데이터는 먼저 UTF-8 문자 인코딩 [STD63]에 따라 옥텟으로 인코딩하는 것이 좋습니다. 그런 다음 비예약 집합의 문자에 해당하지 않는 옥텟만 퍼센트 인코딩하는 것이 좋습니다. 예를 들어 문자 A는 "A"로, 문자 LATIN CAPITAL LETTER A WITH GRAVE는 "%C3%80"으로, 문자 KATAKANA LETTER A는 "%E3%82%A2"로 표현됩니다. 3. 구문 구성요소 일반 URI 구문은 스킴, 권한, 경로, 쿼리 및 프래그먼트라고 하는 구성요소의 계층적 시퀀스로 이루어집니다. URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty 스킴과 경로 구성요소는 필수이지만 경로는 비어 있을 수 있습니다(문자 없음). authority가 있으면 경로는 비어 있거나 슬래시("/") 문자로 시작해야 합니다. authority가 없으면 경로는 두 개의 슬래시 문자("//")로 시작할 수 없습니다. 이러한 제한으로 인해 경로에 대한 서로 다른 다섯 개의 ABNF 규칙(제3.3절)이 생기며, 주어진 URI 참조에는 그중 하나만 일치합니다. 다음은 두 개의 URI 예와 각각의 구성요소입니다. foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / \ urn:example:animal:ferret:nose Berners-Lee 외 표준 트랙 [16페이지]
RFC 3986 URI 일반 구문 2005년 1월 3.1. 스킴 각 URI는 해당 스킴 내에서 식별자를 할당하기 위한 명세를 참조하는 스킴 이름으로 시작합니다. 따라서 URI 구문은 연합되고 확장 가능한 명명 시스템이며, 각 스킴의 명세는 해당 스킴을 사용하는 식별자의 구문 및 의미론을 추가로 제한할 수 있습니다. 스킴 이름은 문자로 시작하고 그 뒤에 문자, 숫자, 더하기 ("+"), 마침표(".") 또는 하이픈("-")의 임의 조합이 오는 문자 시퀀스로 구성됩니다. 스킴은 대소문자를 구분하지 않지만, 정규 형식은 소문자이며 스킴을 명세하는 문서는 반드시 소문자를 사용해야 합니다. 구현은 견고성을 위해 스킴 이름의 대문자를 소문자와 동등하게 받아들이는 것이 좋지만 (예: "http"뿐 아니라 "HTTP"도 허용), 일관성을 위해 소문자 스킴 이름만 생성하는 것이 좋습니다. scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 개별 스킴은 이 문서에서 명세하지 않습니다. 새로운 URI 스킴 등록 절차는 [BCP35]에서 별도로 정의됩니다. 스킴 레지스트리는 스킴 이름과 그 명세 사이의 매핑을 유지합니다. 새로운 URI 스킴 설계자를 위한 조언은 [RFC2718]에서 확인할 수 있습니다. URI 스킴 명세는 스킴별 구문과 일치하는 모든 문자열이 제4.3절에 설명된 <absolute-URI> 문법에도 일치하도록 자체 구문을 정의해야 합니다. 하나 이상의 스킴별 제한을 위반하는 URI가 주어진 경우, 스킴별 해결 과정은 사용되지 않는 부분을 무시하기보다 해당 참조를 오류로 표시하는 것이 좋습니다. 이렇게 하면 동등한 URI의 수를 줄이고 사용자를 오도하도록 URI가 구성되었음을 나타낼 수 있는 일반 구문의 오용을 탐지하는 데 도움이 됩니다(제7.6절). 3.2. 권한 많은 URI 스킴은 URI의 나머지 부분이 정의하는 이름 공간의 관리를 명명 기관에 위임할 수 있도록 명명 권한에 대한 계층적 요소를 포함합니다(해당 기관은 다시 그 권한을 추가로 위임할 수 있습니다). 일반 구문은 등록된 이름 또는 서버 주소를 기반으로 하는 권한을, 선택적 포트 및 사용자 정보와 함께 구별할 수 있는 공통 수단을 제공합니다. authority 구성요소 앞에는 이중 슬래시("//")가 오며, 다음 슬래시("/"), 물음표("?"), 번호 기호("#") 문자 또는 URI 끝에서 종료됩니다. Berners-Lee 외 표준 트랙 [17페이지]
RFC 3986 URI 일반 구문 2005년 1월 authority = [ userinfo "@" ] host [ ":" port ] URI 생성자 및 정규화기는 포트 구성요소가 비어 있는 경우 호스트와 포트를 구분하는 ":" 구분자를 생략하는 것이 좋습니다. 일부 스킴은 userinfo 및/또는 port 하위 구성요소를 허용하지 않습니다. URI에 authority 구성요소가 포함된 경우 경로 구성요소는 비어 있거나 슬래시("/") 문자로 시작해야 합니다. 검증하지 않는 파서(URI 참조를 단순히 주요 구성요소로 분리하는 파서)는 URI가 역참조될 때까지 authority의 하위 구성요소 구조를 무시하고 이중 슬래시부터 첫 번째 종료 구분자까지를 불투명 문자열로 취급하는 경우가 많습니다. 3.2.1. 사용자 정보 userinfo 하위 구성요소는 사용자 이름과, 선택적으로 자원에 접근할 권한을 얻는 방법에 관한 스킴별 정보로 구성될 수 있습니다. 사용자 정보가 있는 경우 그 뒤에는 호스트와 구분하는 앳 기호("@")가 옵니다. userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) userinfo 필드에서 "user:password" 형식을 사용하는 것은 폐기되었습니다. 애플리케이션은 userinfo 하위 구성요소 내에서 발견된 첫 번째 콜론(":") 문자 뒤의 데이터가 빈 문자열(암호 없음 표시)이 아닌 한 이를 일반 텍스트로 렌더링하지 않는 것이 좋습니다. 애플리케이션은 이러한 데이터가 참조의 일부로 수신되면 무시하거나 거부할 수 있으며, 이러한 데이터를 암호화되지 않은 형태로 저장하는 것을 거부하는 것이 좋습니다. 인증 정보를 일반 텍스트로 전달하는 것은 사용된 거의 모든 경우에 보안 위험인 것으로 확인되었습니다. 그래픽 하이퍼텍스트 브라우징처럼 사용자 피드백을 위해 URI를 렌더링하는 애플리케이션은 가능한 경우 userinfo를 URI의 나머지 부분과 구별되는 방식으로 렌더링하는 것이 좋습니다. 이러한 렌더링은 userinfo가 신뢰할 수 있는 도메인 이름처럼 보이도록 오해를 유도하게 구성된 경우 사용자에게 도움이 됩니다 (제7.6절). 3.2.2. 호스트 authority의 host 하위 구성요소는 대괄호로 둘러싼 IP 리터럴, 점으로 구분된 10진수 형식의 IPv4 주소 또는 등록된 이름으로 식별됩니다. host 하위 구성요소는 대소문자를 구분하지 않습니다. URI에 host 하위 구성요소가 존재한다고 해서 해당 스킴이 인터넷에서 주어진 호스트에 접근해야 한다는 의미는 아닙니다. 많은 경우 host 구문은 단지 Berners-Lee 외 표준 트랙 [18페이지]
RFC 3986 URI 일반 구문 2005년 1월 DNS를 위해 만들어지고 배포된 기존 등록 절차를 재사용하여 별도의 레지스트리를 배포하는 비용 없이 전역적으로 고유한 이름을 얻기 위한 목적으로 사용됩니다. 그러나 이러한 사용에는 자체 비용이 따릅니다. URI 생성자가 예상하지 못한 이유로 도메인 이름 소유권이 시간에 따라 변경될 수 있습니다. 다른 경우 host 구성요소의 데이터는 인터넷 호스트와 아무 관련이 없는 등록된 이름을 식별합니다. 이 ABNF 규칙에 "host"라는 이름을 사용하는 이유는 이것이 가장 일반적인 용도이기 때문이며, 유일한 용도이기 때문은 아닙니다. host = IP-literal / IPv4address / reg-name host의 구문 규칙은 IPv4address와 reg-name을 완전히 구별하지 않기 때문에 모호합니다. 구문의 모호성을 해소하기 위해 "첫 번째 일치가 우선" 알고리즘을 적용합니다. host가 IPv4address 규칙과 일치하면 reg-name이 아니라 IPv4 주소 리터럴로 간주하는 것이 좋습니다. host는 대소문자를 구분하지 않지만, 생성자 및 정규화기는 통일성을 위해 등록된 이름과 16진수 주소에 소문자를 사용하는 것이 좋으며, 퍼센트 인코딩에만 대문자를 사용하는 것이 좋습니다. 인터넷 프로토콜 리터럴 주소 버전 6 [RFC3513] 이상으로 식별되는 호스트는 IP 리터럴을 대괄호("[" 및 "]")로 둘러싸 구별합니다. URI 구문에서 대괄호 문자가 허용되는 곳은 이 위치뿐입니다. 아직 정의되지 않은 미래의 IP 리터럴 주소 형식을 고려하여 구현은 휴리스틱 결정에 의존하는 대신 선택적 버전 플래그를 사용하여 해당 형식을 명시적으로 나타낼 수 있습니다. IP-literal = "[" ( IPv6address / IPvFuture ) "]" IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) 버전 플래그는 IP 버전을 나타내는 것이 아니라 리터럴 형식의 미래 버전을 나타냅니다. 따라서 구현은 아래에 설명된 기존 IPv4 및 IPv6 리터럴 주소 형식에 버전 플래그를 제공해서는 안 됩니다. 버전 플래그가 존재함을 나타내는 "v"(대소문자 구분 없음)로 시작하는 IP-literal을 포함한 URI를, 해당 버전 플래그의 의미를 알지 못하는 애플리케이션이 역참조하는 경우 애플리케이션은 "주소 메커니즘이 지원되지 않음"에 적절한 오류를 반환하는 것이 좋습니다. IPv6 리터럴 주소로 식별되는 호스트는 앞에 버전 플래그 없이 대괄호 안에 표현됩니다. 여기에 제공된 ABNF는 [RFC3513]에 제공된 IPv6 리터럴 주소의 텍스트 정의를 변환한 것입니다. 이 구문은 IPv6 범위 지정 주소의 영역 식별자를 지원하지 않습니다. Berners-Lee 외 표준 트랙 [19페이지]
RFC 3986 URI 일반 구문 2005년 1월 128비트 IPv6 주소는 여덟 개의 16비트 조각으로 나뉩니다. 각 조각은 1개에서 4개의 16진수 숫자를 사용하여 대소문자를 구분하지 않는 16진수로 숫자 표현됩니다 (앞의 0은 허용됨). 인코딩된 여덟 조각은 가장 중요한 조각부터 콜론 문자로 구분하여 나열합니다. 선택적으로 가장 덜 중요한 두 조각은 대신 IPv4 주소 텍스트 형식으로 표현할 수 있습니다. 주소 내에서 값이 0인 하나 이상의 연속된 16비트 조각은 모든 숫자를 생략하고 그 위치에 정확히 두 개의 연속된 콜론을 남겨 생략을 표시할 수 있습니다. 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 ] "::" ls32 = ( h16 ":" h16 ) / IPv4address ; 주소의 최하위 32비트 h16 = 1*4HEXDIG ; 16진수로 표현된 주소의 16비트 IPv4 리터럴 주소로 식별되는 호스트는 [RFC1123]에서 [RFC0952]를 참조하여 설명하는 것처럼 점으로 구분된 10진수 표기법(0에서 255 범위의 네 개 10진수를 "."로 구분한 시퀀스)으로 표현됩니다. 제7.4절에 설명된 것처럼 일부 플랫폼에서는 다른 형태의 점 표기법을 해석할 수 있지만, 이 문법에서는 네 옥텟의 점으로 구분된 10진수 형식만 허용합니다. 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 등록된 이름으로 식별되는 호스트는 일반적으로 로컬에서 정의된 호스트 또는 서비스 이름 레지스트리에서 조회하도록 의도된 문자 시퀀스입니다. 다만 URI의 스킴별 의미론에서는 특정 레지스트리(또는 고정 이름 테이블)를 대신 사용하도록 요구할 수 있습니다. 가장 일반적인 이름 레지스트리 메커니즘은 도메인 이름 시스템(DNS)입니다. DNS에서 조회하도록 의도된 등록된 이름은 다음 구문을 사용합니다. Berners-Lee 외 표준 트랙 [20페이지]
RFC 3986 URI 일반 구문 2005년 1월 [RFC1034]의 제 3.5절 및 [RFC1123]의 제 2.1절에 정의되어 있습니다. 이러한 이름은 "."로 구분된 도메인 레이블의 시퀀스로 구성되며, 각 도메인 레이블은 영숫자 문자로 시작하고 끝나고 "-" 문자를 포함할 수도 있습니다. DNS의 완전한 도메인 이름에서 가장 오른쪽 도메인 레이블 뒤에는 하나의 "."를 붙일 수 있으며, 완전한 도메인 이름과 일부 로컬 도메인을 구별해야 하는 경우에는 그렇게 하는 것이 좋습니다. reg-name = *( unreserved / pct-encoded / sub-delims ) URI 스킴이 host에 대한 기본값을 정의한다면 host 하위 구성요소가 정의되지 않았거나 등록된 이름이 비어 있는 경우(길이 0) 해당 기본값이 적용됩니다. 예를 들어 "file" URI 스킴은 authority 없음, 빈 host 및 "localhost"가 모두 최종 사용자의 컴퓨터를 의미하도록 정의되어 있는 반면, "http" 스킴은 authority 누락 또는 빈 host를 유효하지 않은 것으로 간주합니다. 이 명세는 특정 등록 이름 조회 기술을 요구하지 않으므로 상호 운용성에 필요한 범위를 넘어 reg-name의 구문을 제한하지 않습니다. 대신 등록된 이름 구문 준수 문제를 URI 해결을 수행하는 각 애플리케이션의 운영 체제에 위임하며, 해당 운영 체제가 호스트 식별 목적으로 무엇을 허용할지 결정합니다. URI 해결 구현은 등록된 이름 조회에 DNS, 호스트 테이블, yellow pages, NetInfo, WINS 또는 기타 어떤 시스템이든 사용할 수 있습니다. 그러나 전역 범위를 갖도록 의도된 URI에는 DNS의 완전한 도메인 이름처럼 전역 범위의 명명 시스템이 필요합니다. URI 생성자는 DNS 사용이 즉시 분명하지 않은 경우에도 DNS 구문을 준수하는 이름을 사용하는 것이 좋으며, 이러한 이름은 길이가 255자를 넘지 않도록 하는 것이 좋습니다. reg-name 구문은 기반 이름 해결 기술과 독립적으로 비ASCII 등록 이름을 일관되게 표현할 수 있도록 퍼센트 인코딩된 옥텟을 허용합니다. 비ASCII 문자는 먼저 UTF-8 [STD63]에 따라 인코딩한 다음 해당 UTF-8 시퀀스의 각 옥텟을 URI 문자로 표현하기 위해 반드시 퍼센트 인코딩해야 합니다. URI 생성 애플리케이션은 UTF-8 문자 시퀀스를 표현하는 용도가 아니라면 host에서 퍼센트 인코딩을 사용해서는 안 됩니다. 비ASCII 등록 이름이 DNS를 통해 해결하도록 의도된 국제화 도메인 이름을 나타내는 경우, 이름 조회 전에 IDNA 인코딩 [RFC3490]으로 변환해야 합니다. URI 생성자는 기존 URI 해결기와의 상호 운용성을 최대화하려면 이러한 등록 이름을 퍼센트 인코딩이 아니라 IDNA 인코딩으로 제공하는 것이 좋습니다. Berners-Lee 외 표준 트랙 [21페이지]
RFC 3986 URI 일반 구문 2005년 1월 3.2.3. 포트 authority의 port 하위 구성요소는 host 뒤에 오는 선택적 10진수 포트 번호로 지정되며, 하나의 콜론(":") 문자로 host와 구분됩니다. port = *DIGIT 스킴은 기본 포트를 정의할 수 있습니다. 예를 들어 "http" 스킴은 예약된 TCP 포트 번호에 해당하는 "80"을 기본 포트로 정의합니다. 포트 번호가 지정하는 포트의 유형(예: TCP, UDP, SCTP)은 URI 스킴에 의해 정의됩니다. URI 생성자 및 정규화기는 port가 비어 있거나 그 값이 스킴의 기본값과 동일한 경우 port 구성요소와 ":" 구분자를 생략하는 것이 좋습니다. 3.3. 경로 path 구성요소는 보통 계층적 형태로 구성된 데이터를 포함하며, 비계층적 query 구성요소(제3.4절)의 데이터와 함께 URI의 스킴 및 명명 권한(있는 경우)의 범위 내에서 자원을 식별하는 역할을 합니다. path는 첫 번째 물음표("?") 또는 번호 기호("#") 문자나 URI의 끝에서 종료됩니다. URI에 authority 구성요소가 포함되어 있으면 path 구성요소는 비어 있거나 슬래시("/") 문자로 시작해야 합니다. URI에 authority 구성요소가 없으면 path는 두 개의 슬래시 문자("//")로 시작할 수 없습니다. 또한 URI 참조 (제4.1절)는 상대 경로 참조일 수 있으며, 이 경우 첫 번째 경로 세그먼트에는 콜론(":") 문자를 포함할 수 없습니다. ABNF는 이러한 경우의 모호성을 해소하기 위해 다섯 개의 별도 규칙을 필요로 하며, 주어진 URI 참조 내의 path 부분 문자열에는 그중 하나만 일치합니다. 파서가 이러한 규칙 중 하나와 일치시키는 URI 부분 문자열을 설명하기 위해 일반적인 "path 구성요소"라는 용어를 사용합니다. path = path-abempty ; "/"로 시작하거나 비어 있음 / path-absolute ; "/"로 시작하지만 "//"는 아님 / path-noscheme ; 콜론이 없는 세그먼트로 시작함 / path-rootless ; 세그먼트로 시작함 / path-empty ; 문자 0개 path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> Berners-Lee 외 표준 트랙 [22페이지]
RFC 3986 URI 일반 구문 2005년 1월 segment = *pchar segment-nz = 1*pchar segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; 콜론 ":"이 없는 길이 0이 아닌 세그먼트 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" path는 슬래시("/") 문자로 구분된 경로 세그먼트의 시퀀스로 구성됩니다. URI에는 항상 path가 정의되지만 정의된 path는 비어 있을 수 있습니다(길이 0). 계층을 나타내기 위해 슬래시 문자를 사용하는 것은 URI가 상대 참조의 문맥으로 사용될 경우에만 필요합니다. 예를 들어 URI <mailto:fred@example.com>의 path는 "fred@example.com"인 반면 URI <foo://info.example.com?fred>는 빈 path를 가집니다. "." 및 ".." 경로 세그먼트는 점 세그먼트라고도 하며, 경로 이름 계층 내의 상대 참조를 위해 정의됩니다. 이들은 상대 경로 참조(제4.2절)의 시작 부분에서 이름의 계층 트리 내 상대 위치를 나타내는 데 사용하도록 의도되었습니다. 이는 일부 운영 체제의 파일 디렉터리 구조에서 현재 디렉터리와 상위 디렉터리를 각각 나타내는 역할과 유사합니다. 그러나 파일 시스템과 달리 이러한 점 세그먼트는 URI 경로 계층 내에서만 해석되며 해결 과정(제 5.2절)의 일부로 제거됩니다. 계층적 경로의 점 세그먼트를 제외하면 경로 세그먼트는 일반 구문에 대해 불투명한 것으로 간주됩니다. URI 생성 애플리케이션은 세그먼트에 허용되는 예약 문자를 사용하여 스킴별 또는 역참조 처리기별 하위 구성요소를 구분하는 경우가 많습니다. 예를 들어 세미콜론(";")과 등호("=") 예약 문자는 해당 세그먼트에 적용되는 매개변수 및 매개변수 값을 구분하는 데 자주 사용됩니다. 쉼표(",") 예약 문자도 비슷한 목적으로 자주 사용됩니다. 예를 들어 어떤 URI 생성자는 "name"의 버전 1.1에 대한 참조를 나타내기 위해 "name;v=1.1"과 같은 세그먼트를 사용할 수 있고, 다른 생성자는 같은 것을 나타내기 위해 "name,1.1"과 같은 세그먼트를 사용할 수 있습니다. 매개변수 유형은 스킴별 의미론에 의해 정의될 수 있지만, 대부분의 경우 매개변수 구문은 URI 역참조 알고리즘 구현에 따라 달라집니다. 3.4. 쿼리 query 구성요소는 path 구성요소(제3.3절)의 데이터와 함께 URI의 스킴 및 명명 권한(있는 경우)의 범위 내에서 자원을 식별하는 비계층적 데이터를 포함합니다. query 구성요소는 첫 번째 물음표("?") 문자로 표시되고 번호 기호("#") 문자 또는 URI의 끝에서 종료됩니다. Berners-Lee 외 표준 트랙 [23페이지]
RFC 3986 URI 일반 구문 2005년 1월 query = *( pchar / "/" / "?" ) 슬래시("/")와 물음표("?") 문자는 query 구성요소 내부에서 데이터를 나타낼 수 있습니다. 일부 오래되고 잘못된 구현은 상대 참조의 기준 URI로 사용될 때(제5.1절) 이러한 데이터를 올바르게 처리하지 못할 수 있으므로 주의해야 합니다. 이는 계층적 구분자를 찾을 때 query 데이터와 path 데이터를 구별하지 못하기 때문인 것으로 보입니다. 그러나 query 구성요소는 식별 정보를 "key=value" 쌍의 형태로 운반하는 데 자주 사용되고, 흔히 사용되는 값 중 하나가 다른 URI에 대한 참조이므로 사용 편의성을 위해 이러한 문자를 퍼센트 인코딩하지 않는 편이 더 나을 때도 있습니다. 3.5. 프래그먼트 URI의 프래그먼트 식별자 구성요소는 기본 자원에 대한 참조와 추가 식별 정보를 사용하여 보조 자원을 간접적으로 식별할 수 있게 합니다. 식별된 보조 자원은 기본 자원의 일부 또는 하위 집합, 기본 자원 표현에 대한 어떤 보기, 또는 해당 표현이 정의하거나 설명하는 다른 자원일 수 있습니다. 프래그먼트 식별자 구성요소는 번호 기호("#") 문자의 존재로 표시되며 URI의 끝에서 종료됩니다. fragment = *( pchar / "/" / "?" ) 프래그먼트 식별자의 의미론은 기본 자원에 대해 검색 동작을 수행하여 얻을 수 있는 표현 집합에 의해 정의됩니다. 따라서 프래그먼트의 형식 및 해결은 잠재적으로 검색되는 표현의 미디어 유형 [RFC2046]에 따라 달라집니다. 이러한 검색은 URI가 역참조되는 경우에만 수행됩니다. 그러한 표현이 존재하지 않으면 프래그먼트의 의미론은 알 수 없는 것으로 간주되고 사실상 제한되지 않습니다. 프래그먼트 식별자 의미론은 URI 스킴과 독립적이므로 스킴 명세에서 다시 정의할 수 없습니다. 개별 미디어 유형은 해당 미디어 유형이 보조 자원으로 식별할 수 있는 서로 다른 유형의 하위 집합, 보기 또는 외부 참조를 지정하기 위해 프래그먼트 식별자 구문 내부의 자체 제한 또는 구조를 정의할 수 있습니다. 기본 자원에 여러 표현이 있는 경우, 검색 요청의 속성을 바탕으로 표현을 선택하는 자원 (일명 콘텐츠 협상)에서 흔히 그러하듯, 프래그먼트가 식별하는 것은 이러한 모든 표현에서 일관되어야 합니다. 각 표현은 표현 방식에 관계없이 같은 보조 자원에 해당하도록 프래그먼트를 정의하거나, 프래그먼트를 정의되지 않은 상태 (즉, 찾을 수 없음)로 두는 것이 좋습니다. Berners-Lee 외 표준 트랙 [24페이지]
RFC 3986 URI 일반 구문 2005년 1월 다른 URI와 마찬가지로 프래그먼트 식별자 구성요소를 사용한다고 해서 검색 동작이 수행된다는 의미는 아닙니다. 프래그먼트 식별자가 있는 URI는 기본 자원에 접근할 수 있거나 앞으로 접근하게 된다는 의미 없이 보조 자원을 참조하는 데 사용할 수 있습니다. 프래그먼트 식별자는 정보 검색 시스템에서 클라이언트 측 간접 참조의 주요 형태로서 특별한 역할을 하며, 작성자가 자원 소유자가 간접적으로만 제공하는 기존 자원의 특정 측면을 구체적으로 식별할 수 있게 합니다. 따라서 프래그먼트 식별자는 URI의 스킴별 처리에 사용되지 않습니다. 대신 역참조 전에 프래그먼트 식별자를 URI의 나머지 부분에서 분리하므로, URI 스킴과 관계없이 프래그먼트 자체의 식별 정보는 오직 사용자 에이전트에 의해 역참조됩니다. 이러한 별도 처리는 특히 자원이 시간에 따라 이동할 때 참조를 정확히 리디렉션하기 어렵게 만들어 정보 손실로 인식되는 경우가 많지만, 정보 제공자가 참조 작성자가 자원 내부의 정보를 선택적으로 참조할 권리를 부정하는 것도 방지합니다. 간접 참조는 URI를 사용하는 시스템에 추가적인 유연성과 확장성을 제공하기도 합니다. 새로운 식별 스킴보다 새로운 미디어 유형을 정의하고 배포하는 것이 더 쉽기 때문입니다. 슬래시("/")와 물음표("?") 문자는 프래그먼트 식별자 내부에서 데이터를 나타내는 데 허용됩니다. 일부 오래되고 잘못된 구현은 상대 참조의 기준 URI로 사용될 때(제 5.1절) 이 데이터를 올바르게 처리하지 못할 수 있으므로 주의하십시오. 4. 사용 애플리케이션이 URI를 참조할 때 항상 "URI" 구문 규칙으로 정의된 완전한 참조 형식을 사용하는 것은 아닙니다. 공간을 절약하고 계층적 지역성을 활용하기 위해 많은 인터넷 프로토콜 요소와 미디어 유형 형식은 URI의 축약을 허용하는 반면, 다른 것들은 구문을 특정 URI 형식으로 제한합니다. 이러한 참조 구문의 가장 일반적인 형식은 일반 구문의 설계에 영향을 주고 의존하며 일관된 해석을 위해 통일된 파싱 알고리즘이 필요하므로 이 명세에서 정의합니다. 4.1. URI 참조 URI-reference는 자원 식별자의 가장 일반적인 사용 형태를 나타내는 데 사용됩니다. URI-reference = URI / relative-ref Berners-Lee 외 표준 트랙 [25페이지]
RFC 3986 URI 일반 구문 2005년 1월 URI-reference는 URI 또는 상대 참조입니다. URI-reference의 접두사가 스킴 뒤에 콜론 구분자가 오는 구문과 일치하지 않으면 해당 URI-reference는 상대 참조입니다. URI-reference는 일반적으로 먼저 다섯 개의 URI 구성요소로 파싱하여 어떤 구성요소가 존재하고 참조가 상대적인지 여부를 결정합니다. 그런 다음 각 구성요소를 하위 부분으로 파싱하고 유효성을 검사합니다. URI-reference의 ABNF는 "첫 번째 일치가 우선" 모호성 해소 규칙과 함께 일반 구문을 위한 검증 파서를 정의하기에 충분합니다. 정규 표현식에 익숙한 독자는 임의의 문자열에서 URI 구성요소를 추출하는 검증하지 않는 URI-reference 파서의 예를 부록 B에서 참조하십시오. 4.2. 상대 참조 상대 참조는 계층적 구문(제1.2.3절)을 활용하여 다른 계층적 URI의 이름 공간에 상대적인 URI 참조를 표현합니다. relative-ref = relative-part [ "?" query ] [ "#" fragment ] relative-part = "//" authority path-abempty / path-absolute / path-noscheme / path-empty 상대 참조가 가리키는 URI, 즉 대상 URI는 제5절의 참조 해결 알고리즘을 적용하여 얻습니다. 두 개의 슬래시 문자로 시작하는 상대 참조를 네트워크 경로 참조라고 하며, 이러한 참조는 거의 사용되지 않습니다. 하나의 슬래시 문자로 시작하는 상대 참조를 절대 경로 참조라고 합니다. 슬래시 문자로 시작하지 않는 상대 참조를 상대 경로 참조라고 합니다. 콜론 문자를 포함하는 경로 세그먼트(예: "this:that")는 상대 경로 참조의 첫 번째 세그먼트로 사용할 수 없습니다. 스킴 이름으로 오인될 수 있기 때문입니다. 이러한 세그먼트는 상대 경로 참조가 되도록 점 세그먼트 (예: "https://www.rfc-editor.org/rfc/this:that")가 앞에 와야 합니다. Berners-Lee 외 표준 트랙 [26페이지]
RFC 3986 URI 일반 구문 2005년 1월 4.3. 절대 URI 일부 프로토콜 요소는 프래그먼트 식별자가 없는 URI의 절대 형식만 허용합니다. 예를 들어 이후 상대 참조에서 사용하기 위한 기준 URI를 정의하려면 프래그먼트를 허용하지 않는 absolute-URI 구문 규칙이 필요합니다. absolute-URI = scheme ":" hier-part [ "?" query ] URI 스킴 명세는 스킴별 구문과 일치하는 모든 문자열이 <absolute-URI> 문법에도 일치하도록 자체 구문을 정의해야 합니다. 스킴 명세는 해당 스킴을 통해 식별할 수 있는 자원에 적용될 수 있는지 여부와 관계없이 프래그먼트 식별자 구문 또는 사용을 정의하지 않습니다. 프래그먼트 식별은 스킴 정의와 직교하기 때문입니다. 그러나 스킴 명세에는 적절한 경우 해당 스킴의 URI를 프래그먼트 식별자와 함께 사용하는 예를 포함하여 폭넓은 예를 포함하는 것이 권장됩니다. 4.4. 동일 문서 참조 URI 참조가 프래그먼트 구성요소(있는 경우)를 제외하고 기준 URI(제5.1절)와 동일한 URI를 참조하는 경우, 해당 참조를 "동일 문서" 참조라고 합니다. 동일 문서 참조의 가장 흔한 예는 비어 있거나 번호 기호("#") 구분자 뒤에 프래그먼트 식별자만 포함하는 상대 참조입니다. 동일 문서 참조를 검색 동작을 위해 역참조할 때 해당 참조의 대상은 참조와 동일한 엔터티 (표현, 문서 또는 메시지) 내에 있는 것으로 정의됩니다. 따라서 역참조로 인해 새로운 검색 동작이 발생하지 않는 것이 좋습니다. 6.2.2절 및 6.2.3절에 설명된 것처럼 비교 전에 기준 URI와 대상 URI를 정규화하는 것은 허용되지만 실제로는 거의 수행되지 않습니다. 정규화는 동일 문서 참조 집합을 늘릴 수 있으며 일부 캐싱 애플리케이션에는 이점이 될 수 있습니다. 따라서 참조 작성자는 약간 다르지만 동등한 참조 URI가 특정 애플리케이션에서 동일 문서 참조로 해석될 것인지(또는 그렇지 않을 것인지)를 가정하지 않는 것이 좋습니다. 4.5. 접미사 참조 URI 구문은 URI 스킴을 통한 자원의 명확한 참조와 확장성을 위해 설계되었습니다. 그러나 URI 식별과 사용이 일반화되면서 전통적인 매체(텔레비전, 라디오, 신문, 광고판 등)는 URI의 접미사를 Berners-Lee 외 표준 트랙 [27페이지]
RFC 3986 URI 일반 구문 2005년 1월 참조로 점점 더 많이 사용해 왔으며, 이는 다음과 같이 URI의 authority 및 path 부분만으로 구성됩니다. www.w3.org/Addressing/ 또는 단독으로 DNS 등록 이름만 사용하기도 합니다. 이러한 참조는 주로 기계가 아니라 사람이 해석하도록 의도되며, 문맥 기반 휴리스틱만으로 URI를 완성하기에 충분하다고 가정합니다 (예: "www"로 시작하는 대부분의 등록 이름에는 "http://" URI 접두사가 붙을 가능성이 높음). URI 접미사의 모호성을 해소하기 위한 표준 휴리스틱 집합은 없지만, 많은 클라이언트 구현은 사용자가 이를 입력하고 휴리스틱 방식으로 해결할 수 있게 합니다. 이러한 접미사 참조 사용 관행은 일반적이지만 가능하면 피하는 것이 좋으며, 장기적인 참조가 예상되는 상황에서는 절대 사용하지 않는 것이 좋습니다. 위에서 언급한 휴리스틱은 특히 새로운 URI 스킴이 널리 사용되기 시작하면 시간에 따라 변하며, 문맥 밖에서 사용하면 잘못되는 경우가 많습니다. 또한 [RFC1535]에 설명된 것과 같은 보안 문제를 일으킬 수 있습니다. URI 접미사는 상대 경로 참조와 동일한 구문을 가지므로 상대 참조가 예상되는 문맥에서는 접미사 참조를 사용할 수 없습니다. 따라서 접미사 참조는 대화 상자 및 오프라인 광고처럼 정의된 기준 URI가 없는 곳으로 제한됩니다. 5. 참조 해결 이 절에서는 상대 참조를 허용하는 문맥에서 URI 참조를 해결하여 결과가 제3절의 <URI> 구문 규칙과 일치하는 문자열이 되도록 하는 과정을 정의합니다. 5.1. 기준 URI 설정 "상대"라는 용어는 상대 참조가 적용되는 "기준 URI"가 존재함을 의미합니다. 프래그먼트 전용 참조 (제4.4절)를 제외하면 상대 참조는 기준 URI를 알고 있을 때만 사용할 수 있습니다. 상대적일 수 있는 URI 참조를 파싱하기 전에 파서가 기준 URI를 설정해야 합니다. 기준 URI는 <absolute-URI> 구문 규칙(제4.3절)을 준수해야 합니다. URI 참조에서 기준 URI를 얻는 경우, 해당 참조는 기준 URI로 사용하기 전에 절대 형식으로 변환하고 프래그먼트 구성요소를 제거해야 합니다. Berners-Lee 외 표준 트랙 [28페이지]
RFC 3986 URI 일반 구문 2005년 1월 참조의 기준 URI는 아래에서 우선순위 순으로 설명하는 네 가지 방법 중 하나로 설정할 수 있습니다. 우선순위는 계층으로 생각할 수 있으며, 가장 안쪽에서 정의된 기준 URI가 가장 높은 우선순위를 가집니다. 이를 그래픽으로 나타내면 다음과 같습니다. .----------------------------------------------------------. | .----------------------------------------------------. | | | .----------------------------------------------. | | | | | .----------------------------------------. | | | | | | | .----------------------------------. | | | | | | | | | <relative-reference> | | | | | | | | | `----------------------------------' | | | | | | | | (5.1.1) 콘텐츠에 내장된 기준 URI | | | | | | | `----------------------------------------' | | | | | | (5.1.2) 캡슐화 엔터티의 기준 URI | | | | | | (메시지, 표현 또는 없음) | | | | | `----------------------------------------------' | | | | (5.1.3) 엔터티를 검색하는 데 사용된 URI | | | `----------------------------------------------------' | | (5.1.4) 기본 기준 URI(애플리케이션 종속) | `----------------------------------------------------------' 5.1.1. 콘텐츠에 내장된 기준 URI 특정 미디어 유형에서는 상대 참조를 위한 기준 URI를 콘텐츠 자체에 내장하여 파서가 쉽게 얻을 수 있도록 할 수 있습니다. 이는 일반적인 검색 문맥이 아닌 다른 프로토콜(예: 이메일 또는 USENET 뉴스)을 통해 다른 사람에게 전송될 수 있는 목차와 같은 설명 문서에 유용할 수 있습니다. 각 미디어 유형에 대해 기준 URI를 어떻게 내장할 수 있는지를 명세하는 것은 이 명세의 범위를 벗어납니다. 적절한 구문이 있는 경우 각 미디어 유형과 연관된 데이터 형식 명세에 설명되어 있습니다. 5.1.2. 캡슐화 엔터티의 기준 URI 기준 URI가 내장되어 있지 않으면 기준 URI는 표현의 검색 문맥에 의해 정의됩니다. 메시지 또는 아카이브와 같은 다른 엔터티 내부에 포함된 문서의 경우 검색 문맥은 해당 엔터티입니다. 따라서 표현의 기본 기준 URI는 표현이 캡슐화된 엔터티의 기준 URI입니다. Berners-Lee 외 표준 트랙 [29페이지]
RFC 3986 URI 일반 구문 2005년 1월 MIME 컨테이너 유형(예: message 및 multipart 유형) 내부에 기준 URI를 내장하는 메커니즘은 MHTML [RFC2557]에서 정의합니다. MIME 메시지 헤더 구문을 사용하지 않지만 메시지 내에 어떤 형태의 태그가 지정된 메타데이터를 포함할 수 있는 프로토콜은 메시지의 일부로 기준 URI를 정의하기 위한 자체 구문을 정의할 수 있습니다. 5.1.3. 검색 URI의 기준 URI 기준 URI가 내장되어 있지 않고 표현이 다른 엔터티 안에 캡슐화되어 있지 않은 경우, URI를 사용하여 해당 표현을 검색했다면 그 URI를 기준 URI로 간주해야 합니다. 검색이 리디렉션된 요청의 결과인 경우 마지막으로 사용된 URI(즉, 실제로 표현을 검색하게 한 URI)가 기준 URI임에 유의하십시오. 5.1.4. 기본 기준 URI 위에서 설명한 조건 중 어느 것도 적용되지 않으면 기준 URI는 애플리케이션의 문맥에 의해 정의됩니다. 이 정의는 필연적으로 애플리케이션에 종속되므로 다른 방법 중 하나를 사용하여 기준 URI를 정의하지 않으면 동일한 콘텐츠가 서로 다른 유형의 애플리케이션에서 다르게 해석될 수 있습니다. 상대 참조를 포함하는 표현의 발신자는 해당 참조를 위한 기준 URI를 설정할 수 있도록 보장할 책임이 있습니다. 프래그먼트 전용 참조를 제외하면 상대 참조는 기준 URI가 잘 정의된 상황에서만 신뢰성 있게 사용할 수 있습니다. 5.2. 상대 해결 이 절에서는 주어진 기준 URI에 대해 상대적일 수 있는 URI 참조를 해당 참조 대상의 파싱된 구성요소로 변환하는 알고리즘을 설명합니다. 그런 다음 제5.3절에 설명된 대로 구성요소를 다시 조합하여 대상 URI를 형성할 수 있습니다. 이 알고리즘은 다른 구현의 출력을 테스트하는 데 사용할 수 있는 확정적인 결과를 제공합니다. 애플리케이션은 결과가 이 알고리즘에서 제공하는 것과 일치한다는 조건으로 다른 알고리즘을 사용하여 상대 참조 해결을 구현할 수 있습니다. Berners-Lee 외 표준 트랙 [30페이지]
RFC 3986 URI 일반 구문 2005년 1월 5.2.1. 기준 URI 사전 파싱 기준 URI(Base)는 제5.1절의 절차에 따라 설정하고 제3절에 설명된 다섯 개의 주요 구성요소로 파싱합니다. 기준 URI에는 scheme 구성요소만 반드시 존재해야 하며, 다른 구성요소는 비어 있거나 정의되지 않을 수 있습니다. 관련 구분자가 URI 참조에 나타나지 않으면 구성요소는 정의되지 않은 것입니다. path 구성요소는 비어 있을 수 있지만 정의되지 않는 경우는 없습니다. 6.2.2절 및 6.2.3절에 설명된 기준 URI의 정규화는 선택 사항입니다. URI 참조는 정규화하기 전에 대상 URI로 변환해야 합니다. 5.2.2. 참조 변환 각 URI 참조(R)에 대해 다음 의사 코드는 R을 대상 URI(T)로 변환하는 알고리즘을 설명합니다. -- URI 참조를 다섯 개의 URI 구성요소로 파싱함 -- (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R); -- 비엄격 파서는 참조의 scheme이 기준 URI의 scheme과 -- 동일하면 해당 scheme을 무시할 수 있음. -- if ((not strict) and (R.scheme == Base.scheme)) then undefine(R.scheme); endif; Berners-Lee 외 표준 트랙 [31페이지]
RFC 3986 URI 일반 구문 2005년 1월 if defined(R.scheme) then T.scheme = R.scheme; T.authority = R.authority; T.path = remove_dot_segments(R.path); T.query = R.query; else if defined(R.authority) then T.authority = R.authority; T.path = remove_dot_segments(R.path); T.query = R.query; else if (R.path == "") then T.path = Base.path; if defined(R.query) then T.query = R.query; else T.query = Base.query; endif; else if (R.path starts-with "/") then T.path = remove_dot_segments(R.path); else T.path = merge(Base.path, R.path); T.path = remove_dot_segments(T.path); endif; T.query = R.query; endif; T.authority = Base.authority; endif; T.scheme = Base.scheme; endif; T.fragment = R.fragment; 5.2.3. 경로 병합 위 의사 코드는 상대 경로 참조와 기준 URI의 경로를 병합하기 위한 "merge" 루틴을 참조합니다. 이는 다음과 같이 수행합니다. o 기준 URI에 정의된 authority 구성요소가 있고 path가 비어 있으면 "/"와 참조의 path를 이어 붙인 문자열을 반환합니다. 그렇지 않으면, Berners-Lee 외 표준 트랙 [32페이지]
RFC 3986 URI 일반 구문 2005년 1월 o 기준 URI path의 마지막 세그먼트를 제외한 모든 부분 뒤에 참조의 path 구성요소를 붙인 문자열을 반환합니다 (즉, 기준 URI path에서 가장 오른쪽 "/" 뒤의 모든 문자를 제외하거나, 기준 URI path에 "/" 문자가 없다면 기준 URI path 전체를 제외합니다). 5.2.4. 점 세그먼트 제거 의사 코드는 참조된 경로에서 특수한 "." 및 ".."의 완전한 경로 세그먼트를 해석하고 제거하는 "remove_dot_segments" 루틴도 참조합니다. 이 작업은 경로가 상대적인지 여부와 관계없이 참조에서 경로를 추출한 뒤, 대상 URI를 형성하기 전에 잘못되거나 불필요한 점 세그먼트를 제거하기 위해 수행됩니다. 이 제거 과정을 수행하는 방법은 여러 가지가 있지만, 여기서는 두 개의 문자열 버퍼를 사용하는 간단한 방법을 설명합니다. 1. 입력 버퍼는 이제 결합된 path 구성요소로 초기화하고 출력 버퍼는 빈 문자열로 초기화합니다. 2. 입력 버퍼가 비어 있지 않은 동안 다음과 같이 반복합니다. A. 입력 버퍼가 "../" 또는 "https://www.rfc-editor.org/rfc/" 접두사로 시작하면 입력 버퍼에서 해당 접두사를 제거합니다. 그렇지 않으면, B. 입력 버퍼가 "/./" 또는 "/." 접두사로 시작하고 "."가 완전한 경로 세그먼트라면 해당 접두사를 입력 버퍼의 "/"로 대체합니다. 그렇지 않으면, C. 입력 버퍼가 "/../" 또는 "/.." 접두사로 시작하고 ".."가 완전한 경로 세그먼트라면 해당 접두사를 입력 버퍼의 "/"로 대체하고 출력 버퍼에서 마지막 세그먼트 및 앞의 "/"(있는 경우)를 제거합니다. 그렇지 않으면, D. 입력 버퍼가 "." 또는 ".."만으로 구성되어 있으면 이를 입력 버퍼에서 제거합니다. 그렇지 않으면, E. 입력 버퍼의 첫 번째 경로 세그먼트를 출력 버퍼의 끝으로 이동합니다. 여기에는 처음의 "/" 문자(있는 경우)와 그 뒤부터 다음 "/" 문자 직전 또는 입력 버퍼의 끝까지의 모든 문자가 포함됩니다. 3. 마지막으로 출력 버퍼를 remove_dot_segments의 결과로 반환합니다. Berners-Lee 외 표준 트랙 [33페이지]
RFC 3986 URI 일반 구문 2005년 1월 점 세그먼트는 기준 URI의 이름 계층에 상대적인 식별자를 표현하기 위해 URI 참조에서 사용하도록 의도되었다는 점에 유의하십시오. remove_dot_segments 알고리즘은 추가 점 세그먼트를 오류로 처리하거나 역참조 구현이 잘못 해석하도록 남겨 두는 대신 제거함으로써 해당 계층을 존중합니다. 다음은 병합된 두 경로의 예에 위 단계가 적용되는 방법을 보여 주며, 각 단계 이후의 두 버퍼 상태를 나타냅니다. 단계 출력 버퍼 입력 버퍼 1 : /a/b/c/./../../g 2E: /a /b/c/./../../g 2E: /a/b /c/./../../g 2E: /a/b/c /./../../g 2B: /a/b/c /../../g 2C: /a/b /../g 2C: /a /g 2E: /a/g 단계 출력 버퍼 입력 버퍼 1 : mid/content=5/../6 2E: mid /content=5/../6 2E: mid/content=5 /../6 2C: mid /6 2E: mid/6 일부 애플리케이션에서는 문자열 대신 두 개의 세그먼트 스택을 사용하여 remove_dot_segments 알고리즘을 구현하는 것이 더 효율적일 수 있습니다. 참고: 일부 오래되고 잘못된 구현은 기준 경로와 참조 경로를 병합하기 전에 참조의 query 구성요소와 path 구성요소를 분리하지 못합니다. 이 때문에 query 구성요소에 "/../" 또는 "/./" 문자열이 포함된 경우 상호 운용성 실패가 발생할 수 있으므로 주의하십시오. Berners-Lee 외 표준 트랙 [34페이지]
RFC 3986 URI 일반 구문 2005년 1월 5.3. 구성요소 재조합 파싱된 URI 구성요소는 해당 URI 참조 문자열을 얻기 위해 다시 조합할 수 있습니다. 의사 코드를 사용하면 다음과 같습니다. result = "" if defined(scheme) then append scheme to result; append ":" to result; endif; if defined(authority) then append "//" to result; append authority to result; endif; append path to result; if defined(query) then append "?" to result; append query to result; endif; if defined(fragment) then append "#" to result; append fragment to result; endif; return result; 여기서는 구분자가 참조에 존재하지 않았다는 의미의 정의되지 않은 구성요소와, 구분자가 존재했지만 바로 다음 구성요소 구분자 또는 참조의 끝이 뒤따랐다는 의미의 빈 구성요소를 구별하여 유지하도록 주의하고 있습니다. 5.4. 참조 해결 예 잘 정의된 다음 기준 URI를 가진 표현 내에서 http://a/b/c/d;p?q 상대 참조는 다음과 같이 대상 URI로 변환됩니다. Berners-Lee 외 표준 트랙 [35페이지]
RFC 3986 URI 일반 구문 2005년 1월 5.4.1. 정상 예 "g:h" = "g:h" "g" = "http://a/b/c/g" "https://www.rfc-editor.org/rfc/g" = "http://a/b/c/g" "g/" = "http://a/b/c/g/" "/g" = "http://a/g" "//g" = "http://g" "?y" = "http://a/b/c/d;p?y" "g?y" = "http://a/b/c/g?y" "#s" = "http://a/b/c/d;p?q#s" "g#s" = "http://a/b/c/g#s" "g?y#s" = "http://a/b/c/g?y#s" ";x" = "http://a/b/c/;x" "g;x" = "http://a/b/c/g;x" "g;x?y#s" = "http://a/b/c/g;x?y#s" "" = "http://a/b/c/d;p?q" "." = "http://a/b/c/" "https://www.rfc-editor.org/rfc/" = "http://a/b/c/" ".." = "http://a/b/" "../" = "http://a/b/" "../g" = "http://a/b/g" "../.." = "http://a/" "../../" = "http://a/" "../../g" = "http://a/g" 5.4.2. 비정상 예 다음 비정상적인 예는 일반적인 실제 사용에서 발생할 가능성이 낮지만, 모든 URI 파서는 이를 일관되게 해결할 수 있어야 합니다. 각 예는 위와 동일한 기준을 사용합니다. 파서는 상대 경로 참조에 기준 URI 경로의 계층 수준보다 많은 ".." 세그먼트가 있는 경우를 처리할 때 주의해야 합니다. ".." 구문을 사용하여 URI의 authority 구성요소를 변경할 수 없다는 점에 유의하십시오. "../../../g" = "http://a/g" "../../../../g" = "http://a/g" Berners-Lee 외 표준 트랙 [36페이지]
RFC 3986 URI 일반 구문 2005년 1월 마찬가지로 파서는 "." 및 ".." 점 세그먼트가 path의 완전한 구성요소일 때는 제거해야 하지만, 세그먼트의 일부일 뿐이라면 제거해서는 안 됩니다. "/./g" = "http://a/g" "/../g" = "http://a/g" "g." = "http://a/b/c/g." ".g" = "http://a/b/c/.g" "g.." = "http://a/b/c/g.." "..g" = "http://a/b/c/..g" 상대 참조에서 "." 및 ".." 완전한 경로 세그먼트의 불필요하거나 의미 없는 형식을 사용하는 경우는 더 드뭅니다. "https://www.rfc-editor.org/rfc/../g" = "http://a/b/g" "https://www.rfc-editor.org/rfc/g/." = "http://a/b/c/g/" "g/./h" = "http://a/b/c/g/h" "g/../h" = "http://a/b/c/h" "g;x=1/./y" = "http://a/b/c/g;x=1/y" "g;x=1/../y" = "http://a/b/c/y" 일부 애플리케이션은 기준 경로와 병합하고 점 세그먼트를 제거하기 전에 참조의 query 및/또는 fragment 구성요소를 path 구성요소에서 분리하지 못합니다. 일반적인 프래그먼트 사용에는 계층("/") 문자가 포함되지 않고 query 구성요소도 일반적으로 상대 참조 내에서 사용되지 않으므로 이 오류는 거의 발견되지 않습니다. "g?y/./x" = "http://a/b/c/g?y/./x" "g?y/../x" = "http://a/b/c/g?y/../x" "g#s/./x" = "http://a/b/c/g#s/./x" "g#s/../x" = "http://a/b/c/g#s/../x" 일부 파서는 상대 참조의 스킴 이름이 기준 URI 스킴과 동일한 경우 스킴 이름이 존재하는 것을 허용합니다. 이는 부분 URI에 관한 이전 명세 [RFC1630]의 허점으로 간주됩니다. 사용은 피하는 것이 좋지만 하위 호환성을 위해 허용됩니다. "http:g" = "http:g" ; 엄격한 파서의 경우 / "http://a/b/c/g" ; 하위 호환성의 경우 Berners-Lee 외 표준 트랙 [37페이지]
RFC 3986 URI 일반 구문 2005년 1월 6. 정규화 및 비교 URI에 대한 가장 일반적인 동작 중 하나는 단순 비교입니다. 즉, URI를 사용하여 각각의 자원에 접근하지 않고 두 URI가 동등한지 판단하는 것입니다. 응답 캐시에 접근할 때, 브라우저가 링크 색상을 정하기 위해 방문 기록을 확인할 때, 또는 XML 파서가 이름 공간 내의 태그를 처리할 때마다 비교가 수행됩니다. URI를 비교하기 전의 광범위한 정규화는 검색 공간을 줄이거나 요청 동작 및 응답 저장의 중복을 줄이기 위해 스파이더 및 색인 엔진에서 자주 사용됩니다. URI 비교는 특정한 목적을 위해 수행됩니다. 서로 다른 목적으로 URI를 비교하는 프로토콜 또는 구현은 별칭 식별자를 줄이는 데 어느 정도의 노력을 들여야 하는지와 관련하여 서로 다른 설계 절충을 적용하는 경우가 많습니다. 이 절에서는 URI를 비교하는 데 사용할 수 있는 여러 방법, 그 사이의 절충 및 각 방법을 사용할 수 있는 애플리케이션 유형을 설명합니다. 6.1. 동등성 URI는 자원을 식별하기 위해 존재하므로 동일한 자원을 식별할 때 동등한 것으로 간주하는 것이 자연스럽습니다. 그러나 구현이 두 자원을 완전히 알고 있거나 제어하지 않는 한 비교할 방법이 없으므로 이러한 동등성 정의는 실용성이 크지 않습니다. 따라서 URI의 동등성 또는 차이 판단은 문자열 비교를 기반으로 하며, URI 스킴 정의가 제공하는 추가 규칙을 참조하여 보완할 수 있습니다. 이러한 비교의 가능한 결과를 설명하기 위해 "다름" 및 "동등함"이라는 용어를 사용하지만, 동등성에는 애플리케이션에 따라 달라지는 여러 형태가 있습니다. 두 URI가 동등하다는 것을 판단할 수 있더라도 URI 비교만으로 두 URI가 서로 다른 자원을 식별하는지 판단할 수는 없습니다. 예를 들어 서로 다른 두 도메인 이름의 소유자가 두 이름 모두에서 동일한 자원을 제공하기로 결정하여 서로 다른 두 URI가 생길 수 있습니다. 따라서 비교 방법은 거짓 양성을 엄격하게 피하면서 거짓 음성을 최소화하도록 설계됩니다. 동등성을 검사할 때 애플리케이션은 상대 참조를 직접 비교하지 않는 것이 좋습니다. 비교 전에 참조를 각각의 대상 URI로 변환하는 것이 좋습니다. 표현 검색과 같은 네트워크 동작을 선택하거나 피하기 위해 URI를 비교하는 경우, fragment 구성요소(있는 경우)는 비교에서 제외하는 것이 좋습니다. Berners-Lee 외 표준 트랙 [38페이지]
RFC 3986 URI 일반 구문 2005년 1월 6.2. 비교 단계 실제로 URI의 동등성을 검사하는 데 다양한 방법이 사용됩니다. 이러한 방법은 필요한 처리량과 거짓 음성 가능성을 어느 정도 줄이는지에 따라 하나의 범위를 이룹니다. 위에서 언급했듯이 거짓 음성을 완전히 제거할 수는 없습니다. 실제로 그 가능성을 줄일 수는 있지만, 이를 위해서는 더 많은 처리가 필요하며 모든 애플리케이션에서 비용 효율적인 것은 아닙니다. 이러한 비교 관행의 범위를 사다리로 생각한다면, 다음 논의에서는 비용은 낮지만 거짓 음성이 발생할 가능성이 상대적으로 높은 관행에서 시작하여, 계산 비용은 높지만 거짓 음성 위험이 낮은 관행으로 단계적으로 올라갑니다. 6.2.1. 단순 문자열 비교 두 URI를 문자 문자열로 보았을 때 동일하다면 두 URI가 동등하다고 안전하게 결론 내릴 수 있습니다. 이러한 유형의 동등성 검사는 계산 비용이 매우 낮으며 특히 파싱 분야를 비롯한 다양한 애플리케이션에서 널리 사용됩니다. 문자열의 동등성을 검사하려면 몇 가지 기본적인 주의가 필요합니다. 이 절차는 흔히 "비트 단위" 또는 "바이트 단위" 비교라고 하지만 이는 오해를 불러일으킬 수 있습니다. 문자열의 동등성 검사는 일반적으로 문자열을 구성하는 문자를 첫 번째부터 쌍으로 비교하고, 두 문자열의 모든 문자가 소진되고 모든 문자가 같다고 확인되거나, 문자 쌍이 서로 다르다고 비교되거나, 한 문자열이 다른 문자열보다 먼저 소진될 때까지 진행합니다. 이러한 문자 비교에서는 각 문자 쌍을 비교 가능한 형식으로 만들어야 합니다. 예를 들어 한 URI가 EBCDIC 인코딩의 바이트 배열에 저장되고 두 번째 URI가 Java String 객체 (UTF-16)에 저장되어 있다면 순진하게 비트 단위 비교를 적용할 경우 오류가 발생합니다. 바이트 단위 또는 비트 단위가 아니라 문자 단위의 동등성이라고 표현하는 편이 낫습니다. 실용적으로는 문자별 비교를 공통 문자 인코딩으로 변환한 후 코드 포인트별로 수행하는 것이 좋습니다. 거짓 음성은 URI 별칭의 생성 및 사용으로 인해 발생합니다. 비교 방법과 관계없이 URI 참조를 이미 정규화된 형태(즉, 아래에 설명된 대로 정규화를 적용한 후 생성되는 것과 동일한 형태)로 일관되게 제공하면 불필요한 별칭을 줄일 수 있습니다. Berners-Lee 외 표준 트랙 [39페이지]
RFC 3986 URI 일반 구문 2005년 1월 프로토콜과 데이터 형식은 사람들이나 구현이 스스로의 이익을 위해 URI 참조를 일관되게 제공하거나, 적어도 추가 정규화에서 얻을 수 있는 효율성을 상쇄할 만큼 충분히 일관되게 제공할 것이라는 이론에 따라 일부 URI 비교를 단순 문자열 비교로 제한하는 경우가 많습니다. 6.2.2. 구문 기반 정규화 구현은 이 명세에서 제공하는 정의를 기반으로 한 논리를 사용하여 거짓 음성의 가능성을 줄일 수 있습니다. 이 처리는 문자 단위 문자열 비교보다 비용이 어느 정도 더 높습니다. 예를 들어 이 접근 방식을 사용하는 애플리케이션은 다음 두 URI를 합리적으로 동등하다고 간주할 수 있습니다. example://a/b/c/%7Bfoo%7D eXAMPLE://a/./b/../b/%63/%7bfoo%7d 브라우저와 같은 웹 사용자 에이전트는 일반적으로 캐시된 응답을 사용할 수 있는지 판단할 때 이러한 유형의 URI 정규화를 적용합니다. 구문 기반 정규화에는 대소문자 정규화, 퍼센트 인코딩 정규화 및 점 세그먼트 제거와 같은 기법이 포함됩니다. 6.2.2.1. 대소문자 정규화 모든 URI에서 퍼센트 인코딩 세 문자 묶음 내부의 16진수 숫자(예: "%3a"와 "%3A")는 대소문자를 구분하지 않으므로 A-F 숫자에 대문자를 사용하도록 정규화하는 것이 좋습니다. URI가 일반 구문의 구성요소를 사용하는 경우 구성요소의 구문 동등성 규칙이 항상 적용됩니다. 즉, scheme과 host는 대소문자를 구분하지 않으므로 소문자로 정규화하는 것이 좋습니다. 예를 들어 URI <HTTP://www.EXAMPLE.com/>은 <http://www.example.com/>과 동등합니다. 다른 일반 구문 구성요소는 스킴에서 특별히 달리 정의하지 않는 한 대소문자를 구분하는 것으로 간주됩니다 (제6.2.3절 참조). 6.2.2.2. 퍼센트 인코딩 정규화 퍼센트 인코딩 메커니즘(제2.1절)은 그 밖에는 동일한 URI 사이에 차이가 생기는 흔한 원인입니다. 위에서 언급한 대소문자 정규화 문제 외에도 일부 URI 생성자는 퍼센트 인코딩할 필요가 없는 옥텟을 퍼센트 인코딩하여 인코딩되지 않은 대응 URI와 동등한 URI를 만듭니다. 이러한 URI는 제2.3절에 설명된 것처럼 비예약 문자에 해당하는 모든 퍼센트 인코딩 옥텟을 디코딩하여 정규화하는 것이 좋습니다. Berners-Lee 외 표준 트랙 [40페이지]
RFC 3986 URI 일반 구문 2005년 1월 6.2.2.3. 경로 세그먼트 정규화 완전한 경로 세그먼트 "." 및 ".."는 상대 참조 (제4.1절) 내에서만 사용하도록 의도되며 참조 해결 과정(제5.2절)의 일부로 제거됩니다. 그러나 배포된 일부 구현은 참조가 이미 URI라면 참조 해결이 필요하지 않다고 잘못 가정하여 비상대 경로에 점 세그먼트가 나타났을 때 이를 제거하지 못합니다. URI 정규화기는 제5.2.4절에 설명된 대로 path에 remove_dot_segments 알고리즘을 적용하여 점 세그먼트를 제거하는 것이 좋습니다. 6.2.3. 스킴 기반 정규화 URI의 구문 및 의미론은 각 스킴을 정의하는 명세에 설명된 대로 스킴마다 다릅니다. 구현은 추가 처리 비용을 감수하고 스킴별 규칙을 사용하여 거짓 음성의 가능성을 줄일 수 있습니다. 예를 들어 "http" 스킴은 authority 구성요소를 사용하고, 기본 포트가 "80"이며, 빈 path가 "/"와 동등하다고 정의하므로 다음 네 URI는 동등합니다. http://example.com http://example.com/ http://example.com:/ http://example.com:80/ 일반적으로 authority에 일반 구문을 사용하며 path가 빈 URI는 path가 "/"인 형태로 정규화하는 것이 좋습니다. 마찬가지로 port가 비어 있거나 스킴의 기본값인 명시적 ":port"는 port와 ":" 구분자가 생략된 것과 동등하므로 스킴 기반 정규화에서 제거하는 것이 좋습니다. 예를 들어 위의 두 번째 URI가 "http" 스킴의 정규 형식입니다. 정규화가 스킴에 따라 달라지는 또 다른 경우는 빈 authority 구성요소 또는 빈 host 하위 구성요소의 처리입니다. 많은 스킴 명세에서 빈 authority 또는 host는 오류로 간주됩니다. 다른 스킴에서는 "localhost" 또는 최종 사용자의 호스트와 동등하다고 간주합니다. 스킴이 authority의 기본값을 정의하고 그 기본값에 대한 URI 참조가 필요한 경우, 통일성, 간결성 및 국제화를 위해 참조를 빈 authority로 정규화하는 것이 좋습니다. 그러나 userinfo 또는 port 하위 구성요소 중 하나라도 비어 있지 않다면 host가 기본값과 일치하더라도 명시적으로 지정하는 것이 좋습니다. 스킴 명세에서 허용하지 않는 한 정규화는 연관된 구성요소가 비어 있을 때 구분자를 제거하지 않는 것이 좋습니다. Berners-Lee 외 표준 트랙 [41페이지]
RFC 3986 URI 일반 구문 2005년 1월 예를 들어 URI "http://example.com/?"는 위의 어떤 예와도 동등하다고 가정할 수 없습니다. 마찬가지로 userinfo 하위 구성요소 내의 구분자 존재 여부는 일반적으로 해석에 중요합니다. fragment 구성요소는 스킴 기반 정규화의 대상이 아닙니다. 따라서 끝의 "#"만 다른 두 URI는 스킴과 관계없이 서로 다른 것으로 간주됩니다. 일부 스킴은 대소문자를 구분하지 않는 데이터로 구성되는 추가 하위 구성요소를 정의하여 정규화기가 이 데이터를 공통 대소문자 형태(예: 모두 소문자)로 변환할 수 있도록 암시적으로 허용합니다. 예를 들어 "mailto" URI 스킴처럼 path의 하위 구성요소에 인터넷 호스트 이름이 포함되도록 정의하는 URI 스킴에서는 해당 하위 구성요소가 대소문자를 구분하지 않으므로 대소문자 정규화의 대상이 됩니다 (예: 일반 구문에서는 path 구성요소를 대소문자 구분으로 간주하지만 "mailto:Joe@Example.COM"은 "mailto:Joe@example.com"과 동등합니다). 그 밖의 스킴별 정규화도 가능합니다. 6.2.4. 프로토콜 기반 정규화 거짓 음성 발생을 줄이기 위한 상당한 노력은 웹 스파이더에 비용 효율적인 경우가 많습니다. 따라서 이들은 URI 비교에 더욱 적극적인 기법을 구현합니다. 예를 들어 다음과 같은 URI가 http://example.com/data 끝의 슬래시만 다른 URI로 리디렉션되는 것을 관찰하면 http://example.com/data/ 향후 두 URI를 동등한 것으로 간주할 가능성이 높습니다. 이러한 기법은 자원 접근 결과와 해당 스킴의 역참조 알고리즘에 관한 일반적인 규약 모두에서 동등성이 명확하게 나타나는 경우에만 적절합니다(이 경우 상대 참조 문제를 방지하기 위해 HTTP 원본 서버가 리디렉션을 사용하는 경우). Berners-Lee 외 표준 트랙 [42페이지]
RFC 3986 URI 일반 구문 2005년 1월 7. 보안 고려 사항 URI 자체가 보안 위협을 일으키지는 않습니다. 그러나 URI는 네트워크 자원에 접근하기 위한 간결한 명령 집합을 제공하는 데 자주 사용되므로, URI 내의 데이터를 올바르게 해석하고 해당 데이터가 의도하지 않은 접근을 유발하지 않도록 하며, 일반 텍스트로 공개되어서는 안 되는 데이터를 포함하지 않도록 주의해야 합니다. 7.1. 신뢰성 및 일관성 URI를 사용하여 한 번 정보를 검색했다고 해서 앞으로도 동일한 URI로 같은 정보를 검색할 수 있다는 보장은 없습니다. 또한 해당 URI를 통해 앞으로 검색할 수 있는 정보가 과거에 검색한 정보와 눈에 띄게 유사하다는 보장도 없습니다. URI 구문은 특정 스킴 또는 권한이 이름 공간을 어떻게 배분하거나 시간에 따라 유지하는지를 제한하지 않습니다. 그러한 보장은 해당 이름 공간 및 자원을 관리하는 사람에게서만 얻을 수 있습니다. 특정 URI 스킴은 해당 스킴의 모든 명명 기관에 필요한 경우 이름의 지속성과 같은 추가 의미론을 정의할 수 있습니다. 7.2. 악의적 구성 표현 검색처럼 겉보기에는 무해하고 멱등인 동작을 수행하려는 시도가 실제로는 잠재적으로 피해를 주는 원격 동작을 일으키도록 URI를 구성할 수 있는 경우가 있습니다. 안전하지 않은 URI는 일반적으로 해당 네트워크 프로토콜에 예약된 포트 번호가 아닌 다른 포트 번호를 지정하여 구성됩니다. 클라이언트는 자신도 모르게 다른 프로토콜 서비스를 실행하는 사이트에 접속하고, URI 내부의 데이터에는 이 다른 프로토콜에 따라 해석될 경우 예상하지 못한 동작을 유발하는 명령이 포함됩니다. 이러한 악용의 흔한 예는 포트 구성요소가 "25"인 프로토콜 기반 스킴을 사용하여 사용자 에이전트 소프트웨어가 SMTP 서버를 통해 의도하지 않은 메시지 또는 다른 사람을 사칭하는 메시지를 보내도록 속이는 것입니다. 애플리케이션은 URI를 역참조하는 데 사용하는 프로토콜이 해당 잘 알려진 포트에서 예상되는 프로토콜과 호환되지 않는 한 "잘 알려진 포트" 범위(0 - 1023)의 TCP 포트 번호를 지정하는 URI의 역참조를 방지하는 것이 좋습니다. IANA가 잘 알려진 포트의 레지스트리를 유지하지만, 새로운 서비스의 배포를 막지 않도록 애플리케이션은 이러한 제한을 사용자가 구성할 수 있게 하는 것이 좋습니다. Berners-Lee 외 표준 트랙 [43페이지]
RFC 3986 URI 일반 구문 2005년 1월 URI에 특정 해결 또는 역참조 프로토콜의 구분자와 일치하는 퍼센트 인코딩 옥텟이 포함되어 있는 경우 (예: TELNET 프로토콜의 CR 및 LF 문자), 이러한 퍼센트 인코딩은 해당 프로토콜을 통해 전송하기 전에 디코딩해서는 안 됩니다. 프로토콜을 위반할 수 있는 퍼센트 인코딩을 전송하는 것이, 디코딩된 옥텟이 추가 동작 또는 매개변수로 해석되어 예상하지 못하고 잠재적으로 해로운 원격 동작을 유발하도록 허용하는 것보다 덜 해롭습니다. 7.3. 백엔드 트랜스코딩 URI를 역참조할 때 그 내부의 데이터는 사용자 에이전트와 하나 이상의 서버 모두에서 파싱되는 경우가 많습니다. 예를 들어 HTTP에서 일반적인 사용자 에이전트는 URI를 다섯 개의 주요 구성요소로 파싱하고, authority의 서버에 접근하여 authority, path 및 query 구성요소의 데이터를 서버에 보냅니다. 일반적인 서버는 해당 정보를 받아 path를 세그먼트로, query를 키/값 쌍으로 파싱한 다음 구현별 처리기를 호출하여 요청에 응답합니다. 따라서 URI 전체 또는 분리된 구성요소를 처리하는 서버 구현의 일반적인 보안 문제는 해당 URI의 문자 및 퍼센트 인코딩이 나타내는 옥텟 데이터를 올바르게 해석하는 것입니다. 퍼센트 인코딩된 옥텟은 역참조 과정의 어느 시점에서는 반드시 디코딩해야 합니다. 애플리케이션은 옥텟을 디코딩하기 전에 URI를 구성요소 및 하위 구성요소로 나누어야 합니다. 그렇지 않으면 디코딩된 옥텟이 구분자로 오인될 수 있습니다. URI 내 데이터에 대한 보안 검사는 옥텟을 디코딩한 후 적용하는 것이 좋습니다. 다만 "%00" 퍼센트 인코딩 (NUL)은 특별한 처리가 필요할 수 있으며, 애플리케이션이 구성요소 내부에서 원시 데이터를 받을 것으로 예상하지 않는 경우 거부하는 것이 좋습니다. URI path 해석 과정에서 백엔드 파일 시스템 또는 관련 시스템 함수를 사용하는 경우 특별한 주의가 필요합니다. 파일 시스템은 일반적으로 "/", "\", ":", "[" 및 "]"와 같은 특수 문자와 ".", "..", "...", "aux", "lpt" 등의 특수 장치 이름에 동작상의 의미를 부여합니다. 경우에 따라 그러한 이름의 존재 여부만 검사해도 운영 체제가 일시 중지되거나 관련 없는 시스템 호출을 실행하여 서비스 거부 및 의도하지 않은 데이터 전송에 관한 심각한 보안 문제를 일으킬 수 있습니다. 이 명세에서 그러한 중요한 문자와 장치 이름을 모두 나열하는 것은 불가능합니다. 구현자는 애플리케이션에 연결될 수 있는 저장 장치 유형의 예약된 이름과 문자를 조사하고 URI 구성요소에서 얻은 데이터의 사용을 그에 맞게 제한하는 것이 좋습니다. Berners-Lee 외 표준 트랙 [44페이지]
RFC 3986 URI 일반 구문 2005년 1월 7.4. 드문 IP 주소 형식 IPv4address의 URI 구문은 일반적인 IPv4 주소 리터럴의 점으로 구분된 10진수 형식만 허용하지만, URI를 처리하는 많은 구현은 문자열 리터럴을 실제 IP 주소로 변환하기 위해 gethostbyname() 및 inet_aton()과 같은 플랫폼 종속 시스템 루틴을 사용합니다. 안타깝게도 이러한 시스템 루틴은 제3.2.2절에 설명된 것보다 훨씬 더 다양한 형식을 허용하고 처리하는 경우가 많습니다. 예를 들어 많은 구현은 점으로 구분된 세 숫자의 형식을 허용하며, 마지막 부분을 16비트 수량으로 해석하여 네트워크 주소의 가장 오른쪽 두 바이트에 배치합니다 (예: 클래스 B 네트워크). 마찬가지로 점으로 구분된 두 숫자는 마지막 부분을 24비트 수량으로 해석하여 네트워크 주소의 가장 오른쪽 세 바이트(클래스 A)에 배치함을 의미하고, 하나의 숫자(점 없음)는 32비트 수량으로 해석하여 네트워크 주소에 직접 저장합니다. 혼란을 더하는 것은 일부 구현에서 C 언어의 규칙에 따라 각 점 구분 부분을 10진수, 8진수 또는 16진수로 해석할 수 있다는 점입니다 (즉, 앞의 0x 또는 0X는 16진수를 의미하고, 앞의 0은 8진수를 의미하며, 그 밖의 경우 숫자는 10진수로 해석됩니다). 이러한 추가 IP 주소 형식은 플랫폼 구현 간 차이 때문에 URI 구문에서 허용되지 않습니다. 그러나 애플리케이션이 문자열 리터럴 형식의 IP 주소를 기반으로 자원 접근을 필터링하려 할 경우 보안 문제가 될 수 있습니다. 이러한 필터링을 수행한다면 리터럴을 숫자 형식으로 변환하고 문자열 형식의 접두사 또는 접미사가 아니라 숫자 값을 기준으로 필터링하는 것이 좋습니다. 7.5. 민감한 정보 URI 생성자는 비밀로 유지하려는 사용자 이름 또는 암호가 포함된 URI를 제공하지 않는 것이 좋습니다. URI는 브라우저에 자주 표시되고, 일반 텍스트 북마크에 저장되며, 사용자 에이전트의 방문 기록과 중개 애플리케이션 (프록시)에 기록됩니다. userinfo 구성요소에 암호가 나타나는 것은 폐기되었으며, 'password' 매개변수를 공개하도록 의도한 드문 경우를 제외하면 오류로 간주하거나 단순히 무시하는 것이 좋습니다. 7.6. 의미론적 공격 userinfo 하위 구성요소는 거의 사용되지 않고 authority 구성요소에서 host보다 앞에 나타나므로, 실제로는 잡음 뒤에 숨겨진 다른 권한을 식별하면서 사람에게는 한 (신뢰할 수 있는) 명명 권한을 식별하는 것처럼 보이도록 URI를 구성하는 데 사용할 수 있습니다. 예를 들어 Berners-Lee 외 표준 트랙 [45페이지]
RFC 3986 URI 일반 구문 2005년 1월 ftp://cnn.example.com&story=breaking_news@10.0.0.1/top_story.htm 는 사람에게 host가 'cnn.example.com'이라고 생각하게 만들 수 있지만, 실제 host는 '10.0.0.1'입니다. 오해를 유도하는 userinfo 하위 구성요소는 위 예보다 훨씬 길 수 있다는 점에 유의하십시오. 위와 같은 오해를 유도하는 URI는 소프트웨어 자체를 공격하는 것이 아니라 URI의 의미에 대한 사용자의 선입견을 공격하는 것입니다. 사용자 에이전트는 URI를 렌더링할 때 다양한 구성요소를 구분함으로써 이러한 공격의 영향을 줄일 수 있습니다. 예를 들어 userinfo가 있으면 다른 색상이나 톤으로 렌더링할 수 있지만 완전한 해결책은 없습니다. URI 기반 의미론적 공격에 관한 자세한 내용은 [Siedzik]에서 확인할 수 있습니다. 8. IANA 고려 사항 제3.1절의 <scheme>으로 정의되는 URI 스킴 이름은 [BCP35]에 정의된 절차에 따라 IANA가 관리하는 등록된 이름 공간을 형성합니다. 이 문서에서 요구하는 IANA 조치는 없습니다. 9. 감사의 말 이 명세는 RFC 2396 [RFC2396], RFC 1808 [RFC1808] 및 RFC 1738 [RFC1738]에서 유래했으며, 해당 문서의 감사의 말은 여전히 적용됩니다. 또한 Robert M. Hinden, Brian E. Carpenter 및 Larry Masinter가 [RFC2732]에서 정의한 host 구문의 IPv6 리터럴에 대한 갱신(수정 포함)을 통합합니다. 또한 Gisle Aas, Reese Anschultz, Daniel Barclay, Tim Bray, Mike Brown, Rob Cameron, Jeremy Carroll, Dan Connolly, Adam M. Costello, John Cowan, Jason Diamond, Martin Duerst, Stefan Eissing, Clive D.W. Feather, Al Gilman, Tony Hammond, Elliotte Harold, Pat Hayes, Henry Holtzman, Ian B. Jacobs, Michael Kay, John C. Klensin, Graham Klyne, Dan Kohn, Bruce Lilly, Andrew Main, Dave McAlpin, Ira McDonald, Michael Mealling, Ray Merkert, Stephen Pollei, Julian Reschke, Tomas Rokicki, Miles Sabin, Kai Schaetzl, Mark Thomson, Ronald Tschalaer, Norm Walsh, Marc Warne, Stuart Williams 및 Henry Zongaro의 기여에 깊이 감사드립니다. 10. 참고 문헌 10.1. 규범적 참고 문헌 [ASCII] American National Standards Institute, "부호화 문자 집합 -- 정보 교환을 위한 7비트 미국 표준 코드", ANSI X3.4, 1986. Berners-Lee 외 표준 트랙 [46페이지]
RFC 3986 URI 일반 구문 2005년 1월 [RFC2234] Crocker, D. and P. Overell, "구문 명세를 위한 확장 BNF: ABNF", RFC 2234, 1997년 11월. [STD63] Yergeau, F., "UTF-8, ISO 10646의 변환 형식", STD 63, RFC 3629, 2003년 11월. [UCS] International Organization for Standardization, "정보 기술 - 범용 다중 옥텟 부호화 문자 집합(UCS)", ISO/IEC 10646:2003, 2003년 12월. 10.2. 정보 제공용 참고 문헌 [BCP19] Freed, N. and J. Postel, "IANA 문자 집합 등록 절차", BCP 19, RFC 2978, 2000년 10월. [BCP35] Petke, R. and I. King, "URL 스킴 이름 등록 절차", BCP 35, RFC 2717, 1999년 11월. [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD 인터넷 호스트 테이블 명세", RFC 952, 1985년 10월. [RFC1034] Mockapetris, P., "도메인 이름 - 개념 및 기능", STD 13, RFC 1034, 1987년 11월. [RFC1123] Braden, R., "인터넷 호스트 요구 사항 - 애플리케이션 및 지원", STD 3, RFC 1123, 1989년 10월. [RFC1535] Gavron, E., "널리 배포된 DNS 소프트웨어의 보안 문제 및 제안된 수정", RFC 1535, 1993년 10월. [RFC1630] Berners-Lee, T., "WWW의 범용 자원 식별자: 월드 와이드 웹에서 사용되는 네트워크상의 객체 이름 및 주소 표현을 위한 통합 구문", RFC 1630, 1994년 6월. [RFC1736] Kunze, J., "인터넷 자원 위치 지정자에 대한 기능적 권고 사항", RFC 1736, 1995년 2월. [RFC1737] Sollins, K. and L. Masinter, "통합 자원 이름에 대한 기능 요구 사항", RFC 1737, 1994년 12월. [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "통합 자원 위치 지정자(URL)", RFC 1738, 1994년 12월. [RFC1808] Fielding, R., "상대 통합 자원 위치 지정자", RFC 1808, 1995년 6월. Berners-Lee 외 표준 트랙 [47페이지]
RFC 3986 URI 일반 구문 2005년 1월 [RFC2046] Freed, N. and N. Borenstein, "다목적 인터넷 메일 확장(MIME) 제2부: 미디어 유형", RFC 2046, 1996년 11월. [RFC2141] Moats, R., "URN 구문", RFC 2141, 1997년 5월. [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "통합 자원 식별자(URI): 일반 구문", RFC 2396, 1998년 8월. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "분산 저작을 위한 HTTP 확장 -- WEBDAV", RFC 2518, 1999년 2월. [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "HTML과 같은 집합 문서의 MIME 캡슐화(MHTML)", RFC 2557, 1999년 3월. [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "새로운 URL 스킴에 대한 지침", RFC 2718, 1999년 11월. [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "URL의 리터럴 IPv6 주소 형식", RFC 2732, 1999년 12월. [RFC3305] Mealling, M. and R. Denenberg, "공동 W3C/IETF URI 계획 관심 그룹 보고서: 통합 자원 식별자(URI), URL 및 통합 자원 이름 (URN): 명확화 및 권고 사항", RFC 3305, 2002년 8월. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "애플리케이션의 국제화 도메인 이름(IDNA)", RFC 3490, 2003년 3월. [RFC3513] Hinden, R. and S. Deering, "인터넷 프로토콜 버전 6 (IPv6) 주소 지정 아키텍처", RFC 3513, 2003년 4월. [Siedzik] Siedzik, R., "의미론적 공격: URL에는 무엇이 들어 있는가?", 2001년 4월, <http://www.giac.org/practical/gsec/ Richard_Siedzik_GSEC.pdf>. Berners-Lee 외 표준 트랙 [48페이지]
RFC 3986 URI 일반 구문 2005년 1월 부록 A. URI의 통합 ABNF URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty URI-reference = URI / relative-ref absolute-URI = scheme ":" hier-part [ "?" query ] relative-ref = relative-part [ "?" query ] [ "#" fragment ] relative-part = "//" authority path-abempty / path-absolute / path-noscheme / path-empty scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) authority = [ userinfo "@" ] host [ ":" port ] userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) host = IP-literal / IPv4address / reg-name 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 Berners-Lee 외 표준 트랙 [49페이지]
RFC 3986 URI 일반 구문 2005년 1월 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 reg-name = *( unreserved / pct-encoded / sub-delims ) path = path-abempty ; "/"로 시작하거나 비어 있음 / path-absolute ; "/"로 시작하지만 "//"는 아님 / path-noscheme ; 콜론이 없는 세그먼트로 시작함 / path-rootless ; 세그먼트로 시작함 / path-empty ; 문자 0개 path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> segment = *pchar segment-nz = 1*pchar segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; 콜론 ":"이 없는 길이 0이 아닌 세그먼트 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" query = *( pchar / "/" / "?" ) fragment = *( pchar / "/" / "?" ) pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" 부록 B. 정규 표현식을 사용한 URI 참조 파싱 "첫 번째 일치가 우선" 알고리즘은 POSIX 정규 표현식에서 사용하는 "탐욕적" 모호성 해소 방법과 동일하므로, URI 참조의 가능한 다섯 구성요소를 파싱하는 데 정규 표현식을 사용하는 것은 자연스럽고 일반적입니다. 다음 줄은 올바른 형식의 URI 참조를 구성요소로 분해하기 위한 정규 표현식입니다. Berners-Lee 외 표준 트랙 [50페이지]
RFC 3986 URI 일반 구문 2005년 1월 ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))? 12 3 4 5 6 7 8 9 위 두 번째 줄의 숫자는 가독성을 돕기 위한 것일 뿐이며, 각 하위 표현식(즉, 각 괄호 쌍)의 참조 지점을 나타냅니다. 하위 표현식 <n>에 일치한 값을 $<n>이라고 합니다. 예를 들어 위 표현식을 다음과 일치시키면 http://www.ics.uci.edu/pub/ietf/uri/#Related 다음과 같은 하위 표현식 일치 결과를 얻습니다. $1 = http: $2 = http $3 = //www.ics.uci.edu $4 = www.ics.uci.edu $5 = /pub/ietf/uri/ $6 = <undefined> $7 = <undefined> $8 = #Related $9 = Related 여기서 <undefined>는 위 예의 query 구성요소처럼 해당 구성요소가 존재하지 않음을 나타냅니다. 따라서 다섯 구성요소의 값을 다음과 같이 결정할 수 있습니다. scheme = $2 authority = $4 path = $5 query = $7 fragment = $9 반대 방향으로는 제5.3절의 알고리즘을 사용하여 구성요소에서 URI 참조를 다시 만들 수 있습니다. 부록 C. 문맥에서 URI 구분 URI는 해석을 위한 명확한 문맥을 제공하지 않는 형식을 통해 전송되는 경우가 많습니다. 예를 들어 URI가 일반 텍스트에 포함되는 경우가 많이 있으며, 이메일로 전송된 텍스트, USENET 뉴스 및 인쇄된 종이가 그 예입니다. 이러한 경우 URI를 나머지 텍스트, 특히 URI의 일부로 오인될 수 있는 문장 부호와 구분할 수 있어야 합니다. 실제로 URI는 다양한 방식으로 구분되지만 일반적으로 큰따옴표 "http://example.com/", 꺾쇠괄호 <http://example.com/> 안에 넣거나 단순히 공백을 사용합니다. Berners-Lee 외 표준 트랙 [51페이지]
RFC 3986 URI 일반 구문 2005년 1월 http://example.com/ 이러한 감싸기 문자는 URI의 일부가 아닙니다. 경우에 따라 긴 URI를 여러 줄로 나누기 위해 추가 공백 (스페이스, 줄 바꿈, 탭 등)을 넣어야 할 수 있습니다. URI를 추출할 때 이러한 공백은 무시하는 것이 좋습니다. 하이픈("-") 문자 뒤에는 공백을 삽입하지 않는 것이 좋습니다. 일부 조판기 및 프린터가 줄을 나눌 때 줄 끝에 하이픈을 (잘못) 삽입할 수 있으므로, 하이픈 바로 뒤에 줄 바꿈이 있는 URI를 해석하는 프로그램은 줄 바꿈 주변의 모든 공백을 무시하고 하이픈이 실제 URI의 일부일 수도 있고 아닐 수도 있음을 인식하는 것이 좋습니다. 각 URI 주위에 <> 꺾쇠괄호를 사용하는 것은 특히 내부 공백을 포함한 참조를 구분하는 방식으로 권장됩니다. 접두사 "URL:"(뒤에 공백이 있거나 없어도 됨)은 예전에는 URI를 다른 괄호로 묶인 지정자와 구별하는 데 도움이 되는 방법으로 권장되었지만, 실제로 일반적으로 사용되지 않으며 더 이상 권장되지 않습니다. 견고성을 위해 사용자가 입력한 URI를 받아들이는 소프트웨어는 구분자와 내부 공백을 모두 인식하고 제거하도록 시도하는 것이 좋습니다. 예를 들어 다음 텍스트는 네, Jim, "http://www.w3.org/Addressing/"에서 찾았습니다. 하지만 <ftp://foo.example. com/rfc/>에서도 가져올 수 있을 것입니다. <http://www.ics.uci.edu/pub/ ietf/uri/historical.html#WARNING>의 경고를 확인하십시오. 다음 URI 참조를 포함합니다. http://www.w3.org/Addressing/ ftp://foo.example.com/rfc/ http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING Berners-Lee 외 표준 트랙 [52페이지]
RFC 3986 URI 일반 구문 2005년 1월 부록 D. RFC 2396에서의 변경 사항 D.1. 추가 사항 URI에 대한 ABNF 규칙이 이 용어의 일반적인 사용 방식 중 하나, 즉 선택적 프래그먼트가 있는 절대 URI에 대응하도록 도입되었습니다. IPv6(및 이후 버전) 리터럴은 [RFC2732]에 설명된 대로 authority 구성요소의 host 부분에 가능한 식별자 목록에 추가되었으며, "["와 "]"가 예약 집합에 추가되고 미래의 IP 리터럴 버전을 고려한 버전 플래그도 추가되었습니다. 이제 대괄호는 authority 구성요소 내에서 예약된 것으로 명세되며 host 내의 IP 리터럴 구분자로 사용하는 경우를 제외하고는 허용되지 않습니다. path, query 및 fragment 구성요소의 기술적 정의를 변경하지 않고 이 변경을 수행하기 위해 해당 규칙은 허용되는 문자를 직접 지정하도록 다시 정의되었습니다. [RFC2732]는 IPv6 리터럴 주소의 정의를 [RFC3513]에 위임하지만, 안타깝게도 해당 문서에는 IPv6address에 대한 ABNF 설명이 없으므로, [RFC3513]의 제 2.2절에 정의된 텍스트 표현과 일치하는 새로운 IPv6address ABNF 규칙을 만들었습니다. 마찬가지로 IPv4address의 정의는 각 10진수 옥텟을 0-255 범위로 제한하도록 개선되었습니다. URI 정규화 및 비교에 관한 제6절은 Tim Bray의 의견과 W3C Technical Architecture Group 내부의 논의를 바탕으로 완전히 다시 작성되고 확장되었습니다. D.2. 수정 사항 RFC 2396의 임시 BNF 구문은 [RFC2234]의 ABNF로 대체되었습니다. 이 변경으로 인해 이전에 밑줄 문자를 포함하던 모든 규칙 이름은 대신 대시를 사용하도록 이름을 변경해야 했습니다. 또한 전체 문법을 더 쉽게 이해할 수 있도록 여러 구문 규칙을 제거하거나 단순화했습니다. 폐기된 문법 규칙을 참조하는 명세는 다음 표에 따라 해당 규칙을 대체하여 이해할 수 있습니다. Berners-Lee 외 표준 트랙 [53페이지]
RFC 3986 URI 일반 구문 2005년 1월 +----------------+--------------------------------------------------+ | 폐기된 규칙 | 변환 | +----------------+--------------------------------------------------+ | absoluteURI | absolute-URI | | relativeURI | relative-part [ "?" query ] | | hier_part | ( "//" authority path-abempty / | | | path-absolute ) [ "?" query ] | | | | | opaque_part | path-rootless [ "?" query ] | | net_path | "//" authority path-abempty | | abs_path | path-absolute | | rel_path | path-rootless | | rel_segment | segment-nz-nc | | reg_name | reg-name | | server | authority | | hostport | host [ ":" port ] | | hostname | reg-name | | path_segments | path-abempty | | param | *<pchar excluding ";"> | | | | | uric | unreserved / pct-encoded / ";" / "?" / ":" | | | / "@" / "&" / "=" / "+" / "$" / "," / "/" | | | | | uric_no_slash | unreserved / pct-encoded / ";" / "?" / ":" | | | / "@" / "&" / "=" / "+" / "$" / "," | | | | | mark | "-" / "_" / "." / "!" / "~" / "*" / "'" | | | / "(" / ")" | | | | | escaped | pct-encoded | | hex | HEXDIG | | alphanum | ALPHA / DIGIT | +----------------+--------------------------------------------------+ 스킴별 구문을 정의할 때 위의 폐기된 규칙을 사용하는 것은 권장되지 않습니다. 문자에 관한 제2절은 어떤 문자가 예약되어 있는지, 언제 예약되는지, 그리고 일반 구문에서 구분자로 사용되지 않을 때에도 왜 예약되는지를 설명하도록 다시 작성되었습니다. 느낌표("!"), 별표("*"), 작은따옴표("'"), 여는 괄호와 닫는 괄호("(" 및 ")")를 포함하여 일반적으로 디코딩하기에 안전하지 않은 mark 문자들은 예약 문자와 비예약 문자 간의 구분을 명확히 하고 스킴 설계자가 가장 자주 묻는 질문에 답하기 위해 예약 집합으로 이동되었습니다. 마찬가지로 퍼센트 인코딩 문자에 관한 절도 다시 작성되었으며, 이제 URI 정규화기는 비예약 문자에 해당하는 모든 퍼센트 인코딩 옥텟을 디코딩할 수 있습니다. Berners-Lee 외 표준 트랙 [54페이지]
RFC 3986 URI 일반 구문 2005년 1월 일반적으로 다른 형태의 이스케이프 메커니즘과의 혼동을 줄이기 위해 "escaped" 및 "unescaped"라는 용어는 각각 "percent-encoded" 및 "decoded"로 대체되었습니다. URI 및 URI-reference의 ABNF는 LALR 파서에 더 친화적이고 복잡성을 줄이도록 다시 설계되었습니다. 그 결과 구문 설명의 레이아웃 형식과 함께 uric, uric_no_slash, opaque_part, net_path, abs_path, rel_path, path_segments, rel_segment 및 mark 규칙이 제거되었습니다. "opaque" URI에 대한 모든 참조는 path 구성요소가 계층에 대해 어떻게 불투명할 수 있는지에 관한 더 나은 설명으로 대체되었습니다. relativeURI 규칙은 이것이 URI의 하위 집합인지에 대한 불필요한 혼란을 피하기 위해 relative-ref로 대체되었습니다. 첫 번째 세그먼트에 콜론이 있는 URI-reference를 URI 또는 relative-ref로 파싱할 때의 모호성은 다섯 개의 별도 경로 일치 규칙을 사용하여 제거되었습니다. 프래그먼트 식별자는 일반 구문 구성요소에 관한 절 및 URI와 relative-ref 규칙 내부로 다시 이동되었지만 absolute-URI에서는 계속 제외됩니다. 프래그먼트 구문을 다시 통합한 결과 번호 기호("#") 문자는 예약 집합으로 다시 이동되었습니다. ABNF는 path 구성요소가 비어 있을 수 있도록 수정되었습니다. 이를 통해 실제로 "dav:" 이름 공간 [RFC2518] 및 많은 WWW 브라우저 구현이 내부적으로 사용하는 "about:" 스킴에서처럼 absolute-URI가 "scheme:" 뒤에 아무것도 없는 형태로 구성될 수도 있습니다. authority와 path 사이 경계의 모호성은 다섯 개의 별도 경로 일치 규칙을 사용하여 제거되었습니다. 일반 구문을 사용하는 레지스트리 기반 명명 권한은 이제 host 규칙 내부에 정의됩니다. 이 변경으로 제공된 이름을 로컬 이름 해결 메커니즘에 그대로 전달하는 현재 구현이 명세와 일치할 수 있습니다. 또한 여기서 DNS 이름 형식을 다시 명세할 필요도 없어집니다. 더 나아가 host 구성요소가 퍼센트 인코딩된 옥텟을 포함할 수 있게 되며, 이는 국제화 도메인 이름을 URI에 제공하고 URI 처리보다 상위의 애플리케이션 계층에서 원래 문자 인코딩으로 처리한 다음 UTF-8 문자 인코딩의 등록된 이름으로 IDNA 라이브러리에 전달하기 위해 필요합니다. server, hostport, hostname, domainlabel, toplabel 및 alphanum 규칙은 제거되었습니다. [RFC2396]의 상대 참조 해결 알고리즘은 명확성을 높이고 다음 문제를 수정하기 위해 이번 개정에서 의사 코드로 다시 작성되었습니다. Berners-Lee 외 표준 트랙 [55페이지]
RFC 3986 URI 일반 구문 2005년 1월 o [RFC2396] 제 5.2절의 6a 단계는 path가 없는 기준 URI를 고려하지 못했습니다. o 참조에 빈 path와 정의된 query 구성요소가 있는 경우 대상 URI가 기준 URI의 path 구성요소를 상속하는 [RFC1808]의 동작을 복원했습니다. o URI 참조가 동일 문서 참조인지 여부의 판단을 URI 파서에서 분리하여 배포된 URI 처리 구현의 내부 아키텍처와 일치하는 방식으로 애플리케이션 내부의 URI 처리 인터페이스를 단순화했습니다. 이제 판단은 참조 자체의 형식이 아니라 참조를 절대 형식으로 변환한 뒤 기준 URI와 비교하는 것을 기반으로 합니다. 이러한 변경으로 특히 정규화를 사용하여 별칭을 줄이는 경우 RFC 2396의 규칙보다 더 많은 참조가 이 명세에서 "동일 문서"로 간주될 수 있습니다. 그러나 기존 동일 문서 참조의 상태는 변경되지 않습니다. o 상대 참조 해결 루틴을 두 개의 루틴으로 분리했습니다. merge는 기준 URI path와 상대 경로 참조의 결합을 설명하고, remove_dot_segments는 조합된 path에서 특수 "." 및 ".." 세그먼트를 제거하는 방법을 설명합니다. 이제 remove_dot_segments 알고리즘은 일반적인 구현과 일치하고 실제 URI의 정규화를 개선하기 위해 모든 URI 참조 path에 적용됩니다. 이 변경은 기준 URI에 비계층적 path가 있는 비정상 참조 및 동일 스킴 참조의 파싱에만 영향을 줍니다. 색인 A ABNF 11 절대 27 절대 경로 26 absolute-URI 27 접근 9 authority 17, 18 B 기준 URI 28 C 문자 인코딩 4 문자 4 문자들 8, 11 부호화 문자 집합 4 Berners-Lee 외 표준 트랙 [56페이지]
RFC 3986 URI 일반 구문 2005년 1월 D dec-octet 20 역참조 9 점 세그먼트 23 F fragment 16, 24 G gen-delims 13 일반 구문 6 H h16 20 hier-part 16 계층적 10 host 18 I 식별자 5 IP-literal 19 IPv4 20 IPv4address 19, 20 IPv6 19 IPv6address 19, 20 IPvFuture 19 L 위치 지정자 7 ls32 20 M merge 32 N 이름 7 네트워크 경로 26 P path 16, 22, 26 path-abempty 22 path-absolute 22 path-empty 22 path-noscheme 22 path-rootless 22 path-abempty 16, 22, 26 path-absolute 16, 22, 26 path-empty 16, 22, 26 Berners-Lee 외 표준 트랙 [57페이지]
RFC 3986 URI 일반 구문 2005년 1월 path-rootless 16, 22 pchar 23 pct-encoded 12 퍼센트 인코딩 12 port 22 Q query 16, 23 R reg-name 21 등록된 이름 20 상대 10, 28 상대 경로 26 relative-ref 26 remove_dot_segments 33 표현 9 예약 12 해결 9, 28 자원 5 검색 9 S 동일 문서 27 동일성 9 scheme 16, 17 segment 22, 23 segment-nz 23 segment-nz-nc 23 sub-delims 13 접미사 27 T 전사 8 U 통합 4 비예약 13 URI 문법 absolute-URI 27 ALPHA 11 authority 18 CR 11 dec-octet 20 DIGIT 11 DQUOTE 11 fragment 24 gen-delims 13 Berners-Lee 외 표준 트랙 [58페이지]
RFC 3986 URI 일반 구문 2005년 1월 h16 20 HEXDIG 11 hier-part 16 host 19 IP-literal 19 IPv4address 20 IPv6address 20 IPvFuture 19 LF 11 ls32 20 OCTET 11 path 22 path-abempty 22 path-absolute 22 path-empty 22 path-noscheme 22 path-rootless 22 pchar 23 pct-encoded 12 port 22 query 24 reg-name 21 relative-ref 26 reserved 13 scheme 17 segment 23 segment-nz 23 segment-nz-nc 23 SP 11 sub-delims 13 unreserved 13 URI 16 URI-reference 25 userinfo 18 URI 16 URI-reference 25 URL 7 URN 7 userinfo 18 Berners-Lee 외 표준 트랙 [59페이지]
RFC 3986 URI 일반 구문 2005년 1월 저자 주소 Tim Berners-Lee World Wide Web Consortium Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 USA 전화: +1-617-253-5702 팩스: +1-617-258-5999 이메일: timbl@w3.org URI: http://www.w3.org/People/Berners-Lee/ Roy T. Fielding Day Software 5251 California Ave., Suite 110 Irvine, CA 92617 USA 전화: +1-949-679-2960 팩스: +1-949-679-2972 이메일: fielding@gbiv.com URI: http://roy.gbiv.com/ Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA 전화: +1-408-536-3024 이메일: LMM@acm.org URI: http://larry.masinter.net/ Berners-Lee 외 표준 트랙 [60페이지]
RFC 3986 URI 일반 구문 2005년 1월 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 지식 재산권 IETF는 이 문서에 설명된 기술의 구현 또는 사용과 관련이 있다고 주장될 수 있는 지식 재산권 또는 기타 권리의 유효성이나 범위, 또는 그러한 권리에 따른 라이선스를 이용할 수 있는지 여부나 그 범위에 대해 어떠한 입장도 취하지 않습니다. 또한 그러한 권리를 식별하기 위해 독립적인 노력을 기울였다고 진술하지도 않습니다. IETF 문서의 권리에 관한 IETF의 절차에 대한 정보는 BCP 78 및 BCP 79에서 확인할 수 있습니다. IETF 사무국에 제출된 IPR 공개 자료의 사본과 제공될 라이선스에 대한 보증, 또는 이 명세의 구현자나 사용자가 그러한 독점적 권리를 사용할 수 있도록 일반 라이선스나 허가를 얻기 위해 시도한 결과는 IETF의 온라인 IPR 저장소인 http://www.ietf.org/ipr에서 확인할 수 있습니다. IETF는 이 표준을 구현하는 데 필요할 수 있는 기술에 적용되는 저작권, 특허 또는 특허 출원, 기타 독점적 권리를 알고 있는 모든 이해관계자가 이를 IETF에 알려 주시기를 요청합니다. 해당 정보는 IETF의 ietf- ipr@ietf.org로 보내 주십시오. 감사의 말 RFC Editor 기능에 대한 자금은 현재 Internet Society가 제공하고 있습니다. Berners-Lee 외 표준 트랙 [61페이지]