IMT2000 3GPP - 균일한 자원 식별자

Uniform Resource Identifier
"URI"는 여기로 리디렉션됩니다.기타 용도는 URI(동음이의)를 참조하십시오.
URL과 혼동하지 마십시오.
IMT2000 3GPP - URI (Uniform Resource Identifier)
약칭URI
도메인월드 와이드 웹

URI(Uniform Resource Identifier)는 웹 기술에서 사용되는 논리적 또는 물리적 리소스를 식별하는 고유한 문자 시퀀스입니다.URI는 사람과 장소, 개념 또는 웹 페이지와 책과 같은 정보 자원과 같은 실제 객체를 포함한 모든 것을 식별하는 데 사용될 수 있습니다.일부 URI는 네트워크(인터넷 또는 컴퓨터 파일 시스템 또는 인트라넷과 같은 다른 사설 네트워크)에서 정보 리소스를 찾고 검색하는 수단을 제공합니다. 이들은 URL(Uniform Resource Locators)입니다.URL은 리소스의 위치를 제공합니다.URI는 지정된 위치 또는 URL에서 이름으로 리소스를 식별합니다.다른 URI는 리소스 또는 리소스에 대한 정보를 찾거나 검색하는 방법 없이 고유한 이름만 제공합니다. 이러한 이름은 URN(Uniform Resource Names)입니다.URI를 사용하는 웹 기술은 웹 브라우저에만 국한되지 않습니다.URI는 리소스 기술 프레임워크(RDF)를 사용하여 기술된 모든 것을 식별하는 데 사용됩니다. 예를 들어, 웹 온톨로지 언어(OWL)를 사용하여 정의된 온톨로지의 일부인 개념과 친구의 친구 어휘를 사용하여 기술된 사용자는 각각 개별 URI를 갖게 됩니다.

역사

착상

URI와 URL은 공유 이력을 가지고 있습니다.1990년 팀 버너스 리(Tim Berners-Lee)의 하이퍼텍스트 제안은 하이퍼링크의 대상이 되는 자원을 나타내는 짧은 문자열로서 URL의 개념을 암시적으로 소개했습니다.[1]당시 사람들은 이를 "하이퍼텍스트 이름"[2] 또는 "문서 이름"이라고 불렀습니다.

이후 3년 반 동안 HTML, HTTP, 웹 브라우저 등 월드와이드웹의 핵심 기술이 발전하면서 자원의 주소를 제공하는 문자열과 단순히 자원의 이름을 지정한 문자열을 구분할 필요성이 대두되었습니다.아직 공식적으로 정의되지는 않았지만 Uniform Resource Locator라는 용어는 전자를 대표하게 되었고, Uniform Resource Name은 후자를 대표하게 되었습니다.1992년 7월, IETF "UDI(Universal Document Identifiers) BOF"에 대한 Berners-Lee의 보고서에는 URL(Uniform Resource Locators), URN(원래는 Unique Resource Numbers), 그리고 새로운 작업 그룹의 헌장 필요성이 언급되어 있습니다.[3]1992년 11월 IETF "URI Working Group"이 처음으로 만났습니다.[4]

URL과 URL을 정의하기 위한 논의 과정에서 두 용어로 구현된 개념은 리소스 식별의 기본적이고 포괄적인 개념에 불과하다는 것이 명백해졌습니다.1994년 6월, IETF는 URL과 URL의 존재를 인정하는 Berners-Lee의 첫 번째 Request for Comments를 발표했습니다. 가장 중요한 것은, 그것이 Universal Resource Identifier에 대한 공식 구문(즉, 정확한 구문과 의미론이 그들의 체계에 따라 달라지는 URL과 같은 문자열)을 정의했다는 것입니다.그 외에. RFC1630은 당시 사용 중인 URL 방식의 구문을 요약하려고 시도했습니다.상대적인 URL과 조각 식별자의 존재는 인정했지만 표준화하지는 않았습니다.[5]

세련미

1994년 12월, RFC 1738은 상대 URL과 절대 URL을 공식적으로 정의하고, 일반 URL 구문을 정교화하고, 상대 URL을 절대 형식으로 해결하는 방법을 정의했으며, 사용 중인 URL 체계를 더 잘 열거했습니다.[6]URNs의 합의된 정의와 구문은 1997년 5월 IETF RFC 2141이[7] 발표될 때까지 기다려야 했습니다.

1998년 8월에 IETF RFC 2396이[8] 출판되면서 URI 구문은 별도의 사양이[9] 되었고 일반적으로 URI 및 URL과 관련된 RFC 1630 및 1738의 대부분의 부분이 IETF에 의해 수정 및 확장되었습니다.새로운 RFC는 "URI"에서 "Uniform"으로 "U"의 의미를 "Universal"에서 "Uniform"로 바꿨습니다.

1999년 12월, RFC2732는[10] RFC 2396에 대한 약간의 업데이트를 제공하여 URI가 IPv6 주소를 수용할 수 있도록 하였습니다.RFC 2396의 공동저자인 Roy Fielding에 의해 조정된 두 규격에서 발견된 여러 가지 단점들은 공동체의 노력으로 이어졌고, 2005년 1월에 IETF RFC 3986이[11] 출판되었습니다.이전 표준을 폐지하는 동안, 기존 URL 스킴의 세부사항을 더 이상 쓸모없게 만들지는 않았습니다. RFC 1738은 다른 방법으로 대체된 경우를 제외하고 이러한 스킴을 계속해서 관리합니다.예를 들어, IETF RFC 2616은[12],http계략을 꾸미다동시에, IETF는 RFC 3986의 내용을 전체 표준 STD 66으로 공표하여, 공식적인 인터넷 프로토콜로서 URI 일반 구문의 확립을 반영하였습니다.

2001년 W3C의 TAG(Technical Architecture Group)는 주어진 리소스의 여러 버전을 게시하기 위한 모범 사례 및 표준 URI에 대한 가이드를 발표했습니다.[13]예를 들어, 콘텐츠에 액세스하는 데 사용되는 장치의 용량이나 설정을 조정하기 위해 언어나 크기에 따라 콘텐츠가 다를 수 있습니다.

2002년 8월, IETF RFC 3305는[14] "URL"이라는 용어가 광범위한 대중적 사용에도 불구하고 거의 구식으로 바뀌었다고 지적했고, 그러한 실제 사용에 관계없이 일부 URI가 네트워크 접근성을 암시하는 계획을 가짐으로써 주소 역할을 한다는 것을 상기시켜주는 역할만 합니다.Resource Description Framework와 같은 URI 기반 표준이 분명하게 보여주듯이, 리소스 식별은 인터넷을 통한 리소스 표현의 검색을 제안할 필요도 없고 네트워크 기반 리소스를 의미할 필요도 없습니다.

시맨틱 웹은 HTTP URI 체계를 사용하여 실제 세계에서 문서와 개념을 모두 식별하는데, 이는 두 가지를 구분하는 방법에 대해 혼란을 야기했습니다.TAG는 문제 해결 방법에 대한 이메일을 2005년에 발행했으며, 이는 httpRange-14 해상도로 알려지게 되었습니다.[15]그 후 W3C는 시맨틱 웹을 위한 쿨 URIs라는 제목의 관심 그룹 노트를 발행하였는데, 이 노트는 콘텐츠 협상의 사용과 리디렉션을 위한 HTTP 303 응답 코드에 대해 더 자세히 설명했습니다.[16]

설계.

URL 및 URL

URL(Uniform Resource Name)은 특정 네임스페이스에서 이름으로 리소스를 식별하는 URI입니다.URL은 리소스의 위치나 액세스 방법을 암시하지 않고 리소스에 대해 이야기하는 데 사용될 수 있습니다.예를 들어, ISBN(International Standard Book Number) 시스템에서 ISBN 0-486-27557-4는 셰익스피어의 희곡 로미오와 줄리엣의 특정 판본을 식별합니다.해당 판의 URN은 urn:isbn:0-486-27557-4입니다.그러나 그 책의 복사본을 어디서 찾을 수 있는지에 대해서는 아무런 정보도 주지 않습니다.

URL(Uniform Resource Locator)은 리소스 표현에 대해 동작하거나 리소스 표현을 획득하는 수단, 즉 기본 액세스 메커니즘과 네트워크 위치를 모두 지정하는 URI입니다.예를 들어 URL은http://example.org/wiki/Main_Page다음으로 식별된 리소스를 가리킵니다./wiki/Main_Page, 도메인 이름이 다음인 네트워크 호스트에서 하이퍼텍스트 전송 프로토콜(http:)을 통해 이 표현을 얻을 수 있습니다.example.org. (이 경우 HTTP는 일반적으로 HTML 및 관련 코드 형태임을 의미합니다.HTTP가 헤더에 임의 형식을 지정할 수 있기 때문에 실제로는 그렇지 않습니다.)

URL은 사용자의 이름과 유사하고 URL은 사용자의 주소와 유사합니다.즉, URL은 아이템을 식별하고, URL은 아이템을 찾는 방법을 제공합니다.

기술적 출판물, 특히 IETF와 W3C에 의해 제작된 표준은 보통 2001년 7월 30일의 W3C 권고안에 요약된 견해를 반영하며, 이는 URL과 URN의 어떤 공식적인 세분화를 승인하는 것보다 URI라는 용어의 우선순위를 인정합니다.

URL은 유용하지만 비공식적인 개념입니다. URL은 다른 속성이 아닌 기본 액세스 메커니즘(예: 네트워크 "위치")의 표현을 통해 리소스를 식별하는 URI 유형입니다.[17]

따라서 URL은 네트워크를 통해 리소스를 가리키는 URI일 뿐입니다.[a][18]그러나 비기술적인 맥락과 월드 와이드 웹용 소프트웨어에서 "URL"이라는 용어는 여전히 널리 사용되고 있습니다.또한 http 또는 https 체계를 사용하는 URI의 동의어로 비기술 출판물에서 "웹 주소"라는 용어가 자주 발생합니다.이러한 가정은 예를 들어 해결 가능한 URI와 시각적으로 유사한 XML 네임스페이스의 경우 혼란을 초래할 수 있습니다.

WHATWG에서 제작한 사양은 URI보다 URL을 선호하기 때문에 최신 HTML5 API는 URI보다 URL을 사용합니다.[19]

URL이라는 용어로 표준화합니다. URI와 IRI [Internationalized Resource Identifier]는 그냥 헷갈립니다.실제로는 하나의 알고리즘이 둘 다에 사용되기 때문에 그들을 구별하는 것은 아무에게도 도움이 되지 않습니다.검색결과 인기경진대회에서도 URL이 쉽게 우승합니다.[20]

대부분의 URI 스킴은 원래 특정 프로토콜과 함께 사용되도록 설계되었으며 종종 동일한 이름을 가지지만 프로토콜과는 의미론적으로 다릅니다.예를 들어 스킴 http는 일반적으로 HTTP를 사용하여 웹 리소스와 상호 작용하는 데 사용되지만 스킴 파일에는 프로토콜이 없습니다.

구문

참고 항목:URI 스킴 목록

URI에는 해당 스킴 내에 식별자를 할당하기 위한 규격을 참조하는 스킴이 있습니다.이와 같이, URI 구문은 연합되고 확장 가능한 명명 시스템으로서, 각 스킴의 사양은 그 스킴을 사용하는 식별자들의 구문 및 의미론을 더 제한할 수 있습니다.URI 일반 구문은 모든 URI 스킴의 구문의 상위 집합입니다.1998년 8월에 발표된 RFC 2396에서 처음 정의되었으며 2005년 1월에 발표된 RFC 3986에서 최종 정의되었습니다.[9][21]

URI는 허용된 ASCII 문자 세트)로 구성된 허용된 ASCII 문자 집합으로 구성됩니다.:,/,?,#,[,],그리고.@; 방식 또는 구현별:!,$,&,',(,),*,+,,,;,그리고.= ), unres가 제공된 문자(upperc 및 소문자, 10진수,-,.,_,그리고.~)[23] 및 캐릭터%.[24]구문[24] 구성 요소와 하위 구성 요소는 예약 문자에서 구분자로 구분되며(구성 요소의 일반 예약 문자에서만 구분됨), 예약되지 않은 문자로 표시되는 데이터, 구성 요소와 하위 구성 요소에서 구분자 역할을 하지 않는 예약 문자,[25] 상관 관계가 있는 경우 백분율 인코딩으로 표시되는 데이터를 정의합니다.스폰딩 문자가 허용된 집합 외부에 있거나 구성 요소의 구분 기호 또는 내부에 사용되고 있습니다.식별 데이터 옥텟의 퍼센트 인코딩은 문자로 구성된 3개의 문자의 시퀀스입니다.%그 다음에 해당 옥텟의 숫자 값을 나타내는 두 개의 16진수 숫자가 나옵니다.[24]


URI 일반 구문은 왼쪽에서 오른쪽으로 유의성이 감소하는 순서대로 계층적으로 구성된 다섯 개의 구성 요소로 구성됩니다.[26] 

URI = 스킴 ":" ["//" 권한] 경로 ["?" 쿼리] ["#" 조각]

구성 요소에 연결된 구분 기호가 있고 URI에 구분 기호가 나타나지 않으면 구성 요소가 정의되지 않습니다. 구성 요소와 경로 구성 요소는 항상 정의됩니다.[27]구성 요소에 문자가 없으면 구성 요소가 비어 있고 구성 요소는 항상 비어 있지 않습니다.[26]

권한 구성요소는 하위 구성요소로 구성됩니다.

authority = [userinfo "@"] host [:

이를 구문 다이어그램으로 나타내면 다음과 같습니다.

URI syntax diagram

URI는 다음과 같이 구성됩니다.

  • 비어 있지 않은 스킴 구성요소 뒤에 콜론(:), 문자로 시작하여 문자, 숫자, 더하기()의 순서로 구성됩니다.+), 기간(., 또는 하이픈( )-체계는 대소문자를 구분하지 않지만 표준 양식은 소문자이며 체계를 지정하는 문서는 소문자로 구성해야 합니다.인기있는 계획의 예는 다음과 같습니다.http,https,ftp,mailto,file,data그리고.irc. URI 스킴은 IANA(Internet Assigned Numbers Authority)에 등록되어야 하지만, 실제로는 등록되지 않은 스킴이 사용됩니다.[b]
  • 두 개의 슬래시 앞에 있는 선택적 권한 구성요소(//), 다음을 구성합니다.
    • 선택적 userinfo 하위 구성 요소 뒤에 at 기호(@), 사용자 이름과 선택적 비밀번호 뒤에 콜론()으로 구성될 수 있습니다.:). 형식 사용username:passworduserinfo 하위 구성 요소는 보안상의 이유로 더 이상 사용되지 않습니다.응용 프로그램은 첫 번째 콜론 뒤의 데이터를 클리어 텍스트로 렌더링해서는 안 됩니다.:콜론 뒤의 데이터가 빈 문자열이 아닌 한 userinfo 하위 구성 요소에서 찾을 수 있습니다(암호 없음을 indic).
    • 등록된 이름(호스트 이름을 포함하지만 이에 제한되지는 않음) 또는 IP 주소로 구성된 호스트 하위 구성 요소입니다.IPv4 주소는 도트 십진수 표기법이어야 하며 IPv6 주소는 대괄호([]).[29][c]
    • 콜론 앞에 오는 옵션 포트 하위 구성 요소(:), 10진수로 구성됩니다.
  • 슬래시(slash)로 구분된 경로 세그먼트 시퀀스로 구성된 경로 구성 요소(/URI의 경우 항상 경로가 정의되지만 정의된 경로는 비어 있을 수 있습니다(0 길이).세그먼트가 비어 있으면 두 번 연속 슬래시가 발생할 수도 있습니다(//경로 구성 요소에 있습니다.경로 구성 요소는 파일 시스템 경로와 비슷하거나 정확히 매핑될 수 있지만 항상 파일 시스템 경로와 관련이 있는 것은 아닙니다.권한 구성 요소가 정의된 경우 경로 구성 요소는 비어 있거나 슬래시로 시작해야 합니다(/권한 구성 요소가 정의되지 않으면 경로는 빈 세그먼트(즉, 두 개의 슬래시)로 시작할 수 없습니다.//)—다음 문자는 권한 구성 요소로 해석되기 때문입니다.[31]
http 및 https URI에서 경로의 마지막 부분은 pathinfo로 명명되며 선택 사항입니다.기존의 물리적 자원 이름(예를 들어, 파일, 내부 모듈 프로그램 또는 실행 프로그램)을 참조하지 않고 경로의 첫 번째 부분에 별도로 전달해야 하는 논리적 부분(예를 들어, 명령어 또는 한정자 부분)을 참조하는 0 이상의 경로 세그먼트들로 구성되며, 이는 다음과 같이 관리되는 실행 모듈 또는 프로그램을 식별합니다.웹 서버, 동적 컨텐츠(문서 등)를 선택하거나 요청에 따라 맞춤화하는 데 사용되는 경우가 많습니다(또한 CGI 및 PATH_INFO 등 참조).
예:
URI:"http://www.example.com/questions/3456/my-document"
여기서:"/questions"는 경로의 첫 번째 부분(실행 가능한 모듈 또는 프로그램)이며,"/3456/my-document"pathinfo라는 이름의 경로의 두 번째 부분이며, 이는 다음과 같은 이름의 실행 모듈 또는 프로그램으로 전달됩니다."/questions"요청한 문서를 선택합니다.
쿼리 부분이 없는 pathinfo 부분을 포함하는 http 또는 https URI는 마지막 부분이 '슬러그'일 수 있는 'clean URL'이라고도 할 수 있습니다.
쿼리 구분 기호 예
앰퍼샌드()&) key1=value1&key2=value2
세미콜론();)[d] key1=value1;key2=value2
  • 물음표 앞에 있는 선택적 쿼리 구성요소 (?), hierarch가 아닌 데이터의 쿼리 문자열로 구성됩니다.구문은 잘 정의되어 있지 않지만 관례상 구분 기호로 구분된 속성-값 쌍의 시퀀스인 경우가 많습니다.
  • 해시 앞에 오는 선택적 프래그먼트 구성요소 (#). 프래그먼트는 URI의 나머지에 의해 식별된 기사에서 섹션 헤딩과 같은 2차 자원에 방향을 제공하는 프래그먼트 식별자를 포함합니다.주 자원이 HTML 문서인 경우, 프래그먼트는 종종 특정 요소의 속성이며, 웹 브라우저는 이 요소를 보기로 스크롤합니다.

계획 또는 구현별 예약 문자+스킴, userinfo, host, path, query, fragment에서 사용할 수 있으며 스킴 또는 구현별 예약 문자를 사용할 수 있습니다.!,$,&,',(,),*,,,;,그리고.=userinfo, host, path, query 및 fragment에서 사용할 수 있습니다.추가로, 일반 예약 문자:userinfo, path, query 및 fragment, 일반 예약 문자에서 사용될 수 있습니다.@그리고./경로, 쿼리 및 조각, 일반 예약 문자에서 사용할 수 있습니다.?쿼리 및 프래그먼트에 사용될 수 있습니다.[33]

예제 URI

다음 그림에는 URI의 예시와 구성 요소 부분이 표시되어 있습니다.

userinfo 호스트 포트 ┌--┴------┴--------┐ ┌┴┐ https://john.doe@www.example.com :123/forum/questions/?tag=networking&order=newest#top └-┬-┘ └-┬----------------┘└------------┬------------┘ └┬┘--------- ┘ └ 스킴 권한 경로 쿼리 조각 ldap://[2001:db8:7]/c=GB?objectClass? 한 └┬-┘ └-----------------┘└ 스킴 권한 ┘ └ 쿼리 메일://┘ ┬--------┬ 스킴 권한 쿼리 대상:John.Doe@example.com └-┬--┘ └----┬--------- ┘ 스킴 경로 뉴스: comp.inosystems.www.servers.unix └┬-┘ └------------------- ┘ 스킴 경로 tel:+1-816-555-1212 └┬┘ └------------- ┘ 스킴 경로 telnet://192.0.2.16:80/ └-┬-┬------- ┘│ 스킴 권한 경로 urn: oasis: 이름: 지정: docbook:dtd:xml:4.1.2 └┬┘ └--------- ┘ 스킴 경로 tel:+1-2 ┬ 스킴 경로 tel:+1-2 ┬----------------------- ┘ └ 스킴 경로 tel:+1-816-555-12 ┬----------- --- 스킴 경로 telnet://192.0.2:16:80/ ┘ └ 스킴 권한 경로 urn: oasis:명:명:docbook:dtd:xml:4.1.2 └┬┘ └-----------┘ 스킴 경로 ------------- ┬

DOI(디지털 개체 식별자)는 적절한 구문에 의해 촉진되는 대로 핸들 시스템 내에 적합하고 URI 시스템 내에 적합합니다.

URI 참조

URI 참조는 스킴 구성 요소 뒤에 콜론이 오는 URI 또는 상대 참조입니다.:).[34] 콜론 문자를 포함하는 경로 세그먼트(예:foo:bar경로 구성 요소가 슬래시()로 시작하지 않으면 상대 참조의 첫 번째 경로 세그먼트로 사용할 수 없습니다./스킴 구성 요소로 오인될 수 있습니다.이러한 경로 세그먼트에는 점 경로 세그먼트가 선행되어야 합니다(예:./foo:bar).[35]

웹 문서 마크업 언어는 외부 문서 또는 동일한 논리 문서의 특정 부분과 같은 다른 리소스를 가리키기 위해 URI 참조를 자주 사용합니다.[36]

  • HTML에서, 의 가치.src의 속성imgelement는 URI 참조를 제공하며, 의 값도 마찬가지입니다.href의 속성a아니면link요소;
  • XML에서, 시스템 식별자는 다음에 나타납니다.SYSTEMDTD의 키워드는 fragmentless URI 참조입니다.
  • XSLT에서, 의 값.href의 속성xsl:importelement/instruction은 URI 참조입니다. 마찬가지로 에 대한 첫 번째 인수입니다.document()기능.
https://example.com/path/resource.txt#fragment //example.com/path/resource.txt /path/resource.txt 경로/resource.txt../resource.txt./resource.txt 리소스.txt #

결의안

기본 URI에 대한 URI 참조를 해결하면 대상 URI가 발생합니다.이는 기본 URI가 존재하며 절대 URI(프래그먼트 구성 요소가 없는 URI)임을 의미합니다.기본 URI는 우선 순위에 따라 다음에서 얻을 수 있습니다.[37]

  • URI인 경우 참조 URI 자체;
  • 표현의 내용.
  • 표현을 캡슐화하는 주체.
  • 표현의 실제 검색에 사용되는 URI.
  • 원서의 문맥

잘 정의된 기본 URI가 있는 표현 내에서

http://a/b/c/d;p?q

대상 URI에 대한 상대적 참조는 다음과 같이 해결됩니다.[38]

"g:h" -> "g:h" "g" -> "http://a/b/c/g" "g/g" -> "http://a/b/c/g" "g/" -> "http://a/b/c/g" "/g" -> "http://a/b/g" "/g" -> "http://a/b/c/g" "/g" -> "http://a/b/c/p?y" "g?y" -> "http://a/b/c/g" "#s" -> "http://a/b/c/p?q#s" "g#s" -> "http://a/b/c/g#s" ";x" -> "http://a/b/c/c/g" ";x" -> "http://a/b/c/g" "g;x" -> "http://a/b/c/g" "g;x?y#s" -> "http://a/b/c/g" "" -> "http://a/b/c/" "./" -> "http://a/b/" "../" -> "http://a/b/" "../" -> "http:/a/b/" "../" -> "http://a/" "../" -" "/a/b/" "/a/b/g" "../" -" "//" "/a/b/" "/" "/" "/" "//" "//" "/" "/" "/" "/" "/" "/" "/" "/" "/" "/" "/" "/" "/" "/" "/" "/" "/" "/" "/" "/"/"/"/"/"/"/"/"/"/"/"/"/"/""""/""/"/"/""/"/"

URL munching

URL munning은 일반적으로 "?" 토큰 뒤에 명령을 URL에 추가하는 기술입니다.HTTP에 기능을 추가하는 메커니즘으로 WebDAV에서 일반적으로 사용됩니다.예를 들어 URL에 "checkout" 명령을 추가하는 버전 시스템에서는 다음과 같이 적습니다.http://editing.com/resource/file.php?command=checkout. 이것은 CGI 파서들이 쉽게 사용할 수 있다는 장점이 있으며, 이 경우 HTTP와 기본 리소스 사이의 중개자 역할도 합니다.[39]

XML 네임스페이스와의 관계

XML에서 네임스페이스는 요소와 속성 이름의 집합을 할당할 수 있는 추상 도메인입니다.네임스페이스 이름은 일반 URI 구문을 따라야 하는 문자열입니다.[40]그러나 URI 사양은 어휘 구성 요소뿐만 아니라 의도된 용도에 따라 결정하기 때문에 일반적으로 URI로 간주되지 않습니다.[41]네임스페이스 이름이 반드시 URI 스킴의 시맨틱스를 의미하는 것은 아닙니다. 예를 들어 http:로 시작하는 네임스페이스 이름은 HTTP 사용과 연관성이 없을 수 있습니다.

원래 네임스페이스 이름은 비어 있지 않은 URI 참조의 구문과 일치할 수 있었지만 상대적인 URI 참조의 사용은 W3C에 의해 더 이상 사용되지 않았습니다.[42]XML 1.1의 네임스페이스에 대한 별도의 W3C 사양을 사용하면 IRI(Internationalized Resource Identifier) 참조가 URI 참조 외에 네임스페이스 이름의 기초가 될 수 있습니다.[43]

참고 항목

메모들

  1. ^ W3C/IETF 공동 작업 그룹이 2002년에 발표한 보고서는 다양한 'UR*' 용어와 표준 간의 관계를 놓고 IETF와 W3C 내에서 가지고 있는 다양한 견해를 정상화하는 것을 목표로 합니다.어느 조직에서도 완전한 표준으로 발표되지는 않았지만, 위와 같은 공통적인 이해의 기초가 되었고 그 이후로 많은 표준을 알려주었습니다.
  2. ^ 새로운 URI 스킴을 등록하는 절차는 원래 RFC 2717에 의해 1999년에 정의되었으며, 현재는 2015년 6월에 발표된 RFC 7595에 의해 정의됩니다.[28]
  3. ^ 월드 와이드 웹의 자원과 관련된 URI의 경우, 일부 웹 브라우저는 허용합니다..0삭제할 점-십진수 표기법 부분 또는 사용할 원시 정수 IP 주소.[30]
  4. ^ History RFC 1866(RFC 2854에 의해 폐지됨)은 CGI 작성자가 '&'[32] 외에 ';'를 지원하도록 권장합니다.

참고문헌

  1. ^ Palmer, Sean. "The Early History of HTML". infomesh.net. Retrieved 2020-12-06.
  2. ^ "W3 Naming Schemes". www.w3.org. 1992. Retrieved 2020-12-06.
  3. ^ "Proceedings of the Twenty-Fourth Internet Engineering Task Force" (PDF). p. 193. Retrieved 2021-07-27.
  4. ^ "Proceedings of the Twenty-Fifth Internet Engineering Task Force" (PDF). p. 501. Retrieved 2021-07-27.
  5. ^ Berners-Lee, Tim (June 1994). "Universal Resource Identifiers in WWW". Network Working Group. doi:10.17487/RFC1630. Retrieved 2020-12-06. {{cite journal}}:저널 요구사항 인용 journal=(도움말)
  6. ^ Berners-Lee, Tim (December 1994). "Request for Comments: 1738: Uniform Resource Locators (URL)". tools.ietf.org/html. doi:10.17487/RFC1738. Retrieved 2020-12-06.
  7. ^ Moats, R. (May 1997). "Request for Comments: 2141: URN Syntax". tools.ietf.org. doi:10.17487/RFC2141. Retrieved 2020-12-06.
  8. ^ Berners-Lee, Tim (August 1998). "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax". tools.ietf.org. doi:10.17487/RFC2396. Retrieved 2020-12-06.
  9. ^ a b RFC 2396 (1998).
  10. ^ Hinden, R. (December 1999). "RFC 2732:Format for Literal IPv6 Addresses in URL's". tools.ietf.org. doi:10.17487/RFC2732. Retrieved 2020-12-06.
  11. ^ Berners-Lee, Tim (January 2005). "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax". tools.ietf.org. doi:10.17487/RFC3986. Retrieved 2020-12-06.
  12. ^ Fielding, R. (June 1999). "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1". tools.ietf.org. doi:10.17487/RFC2616. Retrieved 2020-12-06.
  13. ^ Raman, T.V. (2006-11-01). "On Linking Alternative Representations To Enable Discovery And Publishing". www.w3.org. Retrieved 2020-12-06.
  14. ^ Mealling, M. (August 2002). Mealling, M; Denenberg, R (eds.). "RFC 3305: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names". tools.ietf.org. doi:10.17487/RFC3305. Retrieved 2020-12-06.
  15. ^ Fielding, Roy (2005-06-18). "[httpRange-14] Resolved". lists.w3.org. Retrieved 2020-12-06.
  16. ^ Sauermann, Leo (December 2008). "Cool URIs for the Semantic Web". www.w3.org. Retrieved 2020-12-06.
  17. ^ URI Planning Interest Group, W3C/IETF (September 2001). "URIs, URLs, and URNs: Clarifications and Recommendations 1.0". www.w3.org. W3C/IETF. Retrieved 2020-12-08.
  18. ^ 공동 W3C/IETFURI 기획 이익 그룹 (2002)
  19. ^ "URL Standard: 6.3. URL APIs elsewhere".
  20. ^ "URL Standard: Goals".
  21. ^ RFC 3986 (2005).
  22. ^ RFC 3986 (2005), §2.2.
  23. ^ RFC 3986 (2005), §2.3.
  24. ^ a b RFC 3986 (2005), §2.1.
  25. ^ RFC 3986 (2005), §2.
  26. ^ a b RFC 3986 (2005), §3.
  27. ^ RFC 3986 (2005), §5.2.1.
  28. ^ IETF (2015).
  29. ^ RFC 3986 (2005), §3.2.2.
  30. ^ 로렌스 (2014)
  31. ^ RFC 2396 (1998), §3.3.
  32. ^ RFC 1866 (1995), §8.2.1.
  33. ^ RFC 3986 (2005), §A.
  34. ^ RFC 3986 (2005), §4.1.
  35. ^ RFC 3986 (2005), §4.2.
  36. ^ RFC 3986 (2005), §4.4.
  37. ^ RFC 3986 (2005), §5.1.
  38. ^ RFC 3986 (2005), §5.4.
  39. ^ 화이트헤드 1998, 38쪽.
  40. ^ 모리슨 (2006).
  41. ^ 해롤드 (2004)
  42. ^ W3C (2009).
  43. ^ W3C (2006).

추가열람

외부 링크