또한 텍스트와 반대로 이진 데이터를 인코딩하는 스키마를 제외한 모든 경우에 아래의 기존 체계를 사용하는 것이 좋습니다. 예를 들어, 기존의 URI 인코딩 방법은 URI 규격에서 WAIS, FTP, 프로스페로 및 고퍼 주소를 매핑하는 데 사용된다. 다음 예제에서는 모든 부품에 레이블이 지정된 URI를 보여 주습니다. 위에서 언급했듯이 URL 전체 양식은 리소스의 네트워크 위치를 식별하는 URI의 하위 집합인 균일 리소스 로케이터입니다. 이는 웹 리소스에 대한 프로토콜을 정의하여 달성됩니다. URL은 리소스 이름을 정의하는 URN과 달리 리소스를 가져올 수 있는 위치를 정의합니다. 실제 예제에서 이 것을 말하면 URL은 사용자의 거리 주소와 일치합니다. URL은 특정 리소스의 네트워크 위치를 정의하는 URI의 전문화입니다. URN과 달리 URL은 리소스를 가져오는 방법을 정의합니다.

우리는 http://exemple.com 등의 형태로 매일 URL을 사용합니다. 그러나 URL이 HTTP URL일 필요는 없으며 ftp://example.com, smb://example.com 등이 될 수 있습니다. 위의 예제에 표시된 두 개의 슬래시는 일부 구성표에서 요구되지만 아래에 설명된 권한 구성 요소를 포함한 모든 구성표에서 필요하지는 않습니다. 1999년 12월, RFC 2732는 RFC 2396에 대한 사소한 업데이트를 제공하여 URI가 IPv6 주소를 수용할 수 있도록 했습니다. 두 사양에서 발견 된 단점의 숫자는 지역 사회 노력으로 이어졌다, RFC에 의해 조정 2396 공동 저자 로이 필딩, 그 월에 RFC3986의 출판에 절정 2005. 이전 표준을 사용하지 는 동안 기존 URL 스키마의 세부 정보를 더 이상 사용하지 않았습니다. RFC 1738은 달리 대체된 경우를 제외하고 이러한 체계를 계속 관리합니다. 예를 들어 RFC 2616은 http 체계를 구체화합니다.

동시에 IETF는 공식 인터넷 프로토콜로 URI 제네릭 구문을 수립하는 것을 반영하여 RFC 3986의 내용을 전체 표준 STD 66으로 게시했습니다. HTML에서 URI를 사용하여 문서의 특정 섹션을 찾을 수 있으며, 조각 식별자로 참조할 요소의 id 특성 값을 사용할 수 있습니다. 예를 들어 “상대 URI”라고 하는 이전 섹션에는 속성 ID에 “상대 uris” 값이 있습니다. 이 문서의 URI에 해시 기호(“#”)와 id 특성 값(http://www.htmlquick.com/reference/uri-url.html#relative-uris)을 더하여 해당 섹션을 특별히 가리키는 링크를 만들 수 있습니다. 두 가지 구성표가 정의됩니다. 첫 번째 “mid:”는 메일 메시지의 RFC822 메시지 ID를 나타냅니다. 이 식별자는 참조 및 회신-응답 필드와 같은 RFC822에서 이미 사용되었습니다. “mid:” 이후의 URL의 나머지 는 상수 래퍼가 제거된 RFC822 msg-id이며, 의미 체계는 다르지만 실제로 형식이 사서함에 대한 addr-spec 형식과 동일한 형식인 식별자를 남깁니다.

이 논쟁의 문제는 관련 RFC가 매우 조밀하고 혼란스럽고 심지어 모순적이라는 것입니다. 예를 들어 RFC 3986은 URI가 이름, 로케이터 또는 둘 다일 수 있다고 말합니다… 문서 처리를 담당하는 브라우저는 기본 URI와 함께 상대 URI를 사용하여 새 전체 URI를 생성하여 원래 문서의 위치에서 대상 리소스로 디렉터리 구조를 트래버스합니다. 이 개념은 다음 예제와 함께 더 잘 설명될 것입니다. 대부분의 URI 체계는 원래 특정 프로토콜과 함께 사용되도록 설계되었으며 종종 이름이 같은 경우가 많지만 프로토콜과 는 본질적으로 다릅니다.