URN

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

URN(Uniform Resource Name)은 인터넷 정보 아키텍처의 일부로, 리소스의 영구적인 식별을 위해 고안된 식별자이다. URL(Uniform Resource Locator)과 달리 URN은 특정 접근 프로토콜에 의존하지 않고, 정의된 네임스페이스 내에서 고유하게 할당되어 리소스가 더 이상 존재하지 않더라도 지속적인 식별을 보장한다. URN은 "urn:"으로 시작하며, 네임스페이스 식별자(NID)와 네임스페이스 특정 문자열(NSS)로 구성된다. IANA(인터넷 할당 번호 관리 기관)에 URN 네임스페이스를 등록하여 전역적인 고유성을 확보하며, ISBN, ISSN, UUID 등 다양한 국제 표준 식별자를 URN으로 사용할 수 있다.

더 읽어볼만한 페이지

URI 스킴 - HTTPS
HTTPS는 HTTP에 보안 기능이 더해진 통신 규약으로, 웹 브라우저와 서버 간 통신을 암호화하여 보안을 강화하지만, 인증서 비용, 서버 부하, 혼합 콘텐츠 문제 등의 단점도 존재한다.
URI 스킴 - 텔넷
텔넷은 1973년에 정의된 7비트 ASCII 문자 세트를 사용하는 네트워크 프로토콜로, 클라이언트-서버 방식으로 작동하며 TCP 포트 23 또는 2323을 사용하며, 보안 취약성으로 인해 SSH로 대체되고 있다.
식별자 - 아카이벌 리소스 키
아카이벌 리소스 키(ARK)는 디지털, 물리적, 추상적 자원의 영구적인 식별을 위한 체계로, 분산된 웹 환경에서 관리 주체의 약속을 통해 객체의 보존과 접근성을 제공하며, ARK Alliance가 국제적인 사용을 장려하고 한국에서도 활용된다.
식별자 - 바코드
바코드는 다양한 폭의 막대와 공백 조합으로 정보를 나타내는 기호로, 상품 식별, 재고 관리 등에 사용되며 1차원과 2차원 바코드가 존재하고 바코드 스캐너로 판독되어 산업 효율성을 높인다.
인터넷 표준 - DNSSEC
DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
인터넷 표준 - IPv6
IPv6는 IPv4 주소 고갈 문제를 해결하고자 개발된 차세대 인터넷 프로토콜로, 128비트 주소 체계를 통해 사실상 무한대에 가까운 IP 주소를 제공하며, 주소 자동 설정, 패킷 처리 효율성 향상, 보안 기능 강화 등의 특징을 갖는다.

URN
일반 정보
유형	식별자
목적	컴퓨터 시스템에서 이름 지정
개발	인터넷 기술 특별위원회 (IETF)
설명	위치에 독립적인 영구 리소스 식별자
기술 정보
구조	urn:<네임스페이스 식별자>:<네임스페이스 특정 문자열>

2. URI, URN, URL

인터넷 상의 리소스를 가리키는 방법에는 여러 가지가 있으며, 대표적으로 URI, URN, URL이 논의된다.

원래 URN은 리소스 자체에 부여된 영구적이고 위치에 독립적인 식별자(이름)로, URL은 HTTP나 FTP 같은 특정 프로토콜을 사용하여 리소스가 어디에 있는지 알려주는 위치 정보(주소)로 구분되었다. 예를 들어, 특정 책의 ISBN은 URN과 유사하게 책 자체를 식별하지만, 그 책이 있는 서점 웹사이트 주소는 URL에 해당한다고 볼 수 있다.

하지만 기술이 발전하면서 IETF와 W3C는 2000년대 초반부터 이러한 구분을 넘어, 이들을 포괄하는 더 넓은 개념인 URI를 표준으로 채택했다. 현재 공식 기술 표준에서는 URN과 URL의 엄격한 구분을 사용하지 않는다. 모든 인터넷 리소스 식별자는 기본적으로 URI이며, URI 중 일부는 리소스의 위치를 나타내는 기능(로케이터, 전통적인 URL의 역할)을 수행하고, 다른 일부는 단순히 리소스를 식별하는 이름의 역할에 더 중점을 둔다.

그럼에도 불구하고 일상적으로는 여전히 URL이라는 용어가 웹사이트 주소처럼 특정 위치를 나타내는 의미로 널리 사용되고 있다. URN이라는 용어는 본래의 '영구 식별자'라는 개념적 의미와 더불어, 현재는 urn:으로 시작하는 특정 URI 체계(예: urn:isbn)를 가리키는 기술적인 용어로도 사용된다.

2. 1. URI (Uniform Resource Identifier)

URI(Uniform Resource Identifier)는 인터넷 상의 리소스를 식별하거나 이름을 지정하는 데 사용되는 문자열이다. URI는 많은 인터넷 프로토콜에서 정보 리소스를 참조하고 접근하는 데 활용되며, http나 ftp와 같은 잘 알려진 프로토콜 외에도 수백 개의 다른 프로토콜을 포함하는 URI 체계를 가진다.

과거에는 리소스의 위치를 특정 프로토콜(예: HTTP, FTP)과 연결하여 지정하는 URL(Uniform Resource Locator)과, 특정 네임스페이스 내에서 할당되어 영구적이고 위치에 독립적인 식별자인 URN(Uniform Resource Name)을 구분했다. URN은 리소스가 사라지거나 사용할 수 없게 된 후에도 오랫동안 유지되도록 설계되었다.

그러나 2005년 IETF는 RFC 3986을 통해 'Uniform Resource Name'과 'Uniform Resource Locator'라는 용어를 공식적으로 폐기하고, 이를 포괄하는 URI라는 용어를 채택했다. 이는 2001년 W3C와 IETF의 공동 작업 그룹이 제안한 관점을 반영한 것이다. 비록 공식 표준에서는 폐기되었지만, 'URL'이라는 용어는 여전히 널리 사용되고 있다.

현대적인 관점에서 보면, 모든 URI는 리소스를 식별하거나 이름을 지정하며, 그중 일부는 특정 프로토콜과 결합하여 리소스의 표현(representation)으로 연결될 수 있는 '로케이터(locator)'의 역할도 수행한다. 다른 URI들은 로케이터가 아니며 반드시 시스템 내에서 해석(resolve)될 필요는 없고, 단순히 리소스의 이름이나 식별자로 사용될 수 있다. 리소스는 이동할 수 있기 때문에, 특정 위치에 얽매이지 않는 식별자(이름)가 위치를 나타내는 식별자(로케이터)보다 시간이 지나도 고유성과 영속성을 유지할 가능성이 더 높다. 하지만 URI가 실제로 해석 가능한지 여부는 '이름'인지 '로케이터'인지 와는 별개로 여러 운영 및 실제 상황에 따라 달라진다. 따라서 현대적 관점에서는 '이름'과 '로케이터' 사이에 명확한 경계는 없다고 본다.

이러한 관점에 따라, 'URN'이라는 용어는 현재 http:, ftp: 등과 같은 수많은 URI '체계(scheme)' 중 하나인 urn: 체계를 가리키는 것으로 남아있다. urn: 체계를 사용하는 URI는 로케이터가 아니며, 특정 프로토콜이나 접근 방식과 연결될 필요가 없고, 반드시 해석될 필요도 없다. 대신, 이들은 고유성을 유지하고 장기간에 걸쳐 동일한 리소스를 지속적으로 식별하도록 보장하는 절차에 따라 할당되어야 한다. urn:uuid:와 같이 등록 기관 없이 식별자를 할당하는 urn: 네임스페이스도 있지만, 대부분은 그렇지 않다. 대표적인 URN 네임스페이스로는 국제 표준 도서 번호(ISBN)를 나타내는 urn:isbn이 있다. 이러한 관점은 RFC 8141 (2017년)에서도 유지되고 있다.

urn: 체계 외에도 tag:, info:(현재는 대부분 사용되지 않음), ni: 등 로케이터가 아니며 특정 해석이나 접근 프로토콜과 연결되지 않는다는 점에서 urn:과 유사한 다른 URI 체계들이 존재한다.

2. 2. URL (Uniform Resource Locator)

URL(Uniform Resource Locator)은 본래 정보 아키텍처의 일부로 URN과 구별되는 개념으로 고안되었다. URL은 HTTP나 FTP와 같은 특정 접속 규약(프로토콜)을 사용하여 인터넷 상의 리소스가 실제로 어디에 있는지, 즉 리소스의 '위치'를 명시적으로 지정하여 식별하는 방식이다. 이는 리소스 자체에 대해 위치와는 독립적인 영구 식별자를 부여하고자 했던 URN과는 차이가 있었다.

World Wide Web Consortium(W3C)과 Internet Engineering Task Force(IETF)는 2005년부터 Uniform Resource Identifier(URI)라는 더 포괄적인 개념을 도입하면서, 기술 표준에서 URL과 URN의 엄격한 구분을 공식적으로는 사용하지 않게 되었다. URI는 인터넷 상의 리소스를 식별하거나 이름을 붙이는 데 사용되는 문자열 문자이다. URI는 많은 인터넷 프로토콜에서 정보 리소스를 참조하고 접근하는 데 활용된다. URI 체계에는 http 및 ftp 프로토콜과 수백 개의 다른 프로토콜이 포함된다.

현대적인 관점에서 볼 때, 모든 URI는 리소스를 식별하거나 명명하는 역할을 수행한다. 이 중 일부 URI는 특정 프로토콜과 결합하여 리소스의 실제 내용(예: 웹 페이지)으로 연결될 수 있는데, 이러한 기능을 하는 URI를 '로케이터(locator)'라고 부르며, 이는 전통적인 URL이 수행하던 핵심 역할에 해당한다. 반면, 로케이터가 아닌 URI는 반드시 특정 위치로 연결될 필요는 없으며, 이름이나 식별자로서의 역할에 중점을 둔다.

이처럼 기술적인 구분은 모호해졌지만, 일상적으로 'URL'이라는 용어는 여전히 특정 웹사이트 주소나 파일 경로처럼 리소스의 구체적인 위치를 나타내는 식별자를 지칭하는 말로 널리 사용되고 있다.

2. 3. URN (Uniform Resource Name)

URN은 원래 정보 아키텍처의 일환으로 인터넷을 위해 고안되었으며, URL(Uniform Resource Locator), URC(Uniform Resource Characteristic) 및 메타데이터 프레임워크와 함께 사용되었다. RFC 1737 (1994) 및 이후 RFC 2141 (1997)에 설명된 바와 같이, URN은 HTTP나 FTP 같은 특정 접속 프로토콜을 이용해 리소스의 위치를 나타내는 URL과는 구별된다. 반면 URN은 특정 네임스페이스 안에서 할당되는 영구적이고 위치에 독립적인 식별자로 설계되었다. 이는 일반적으로 네임스페이스 담당 기관에 의해 할당되어 전 세계적으로 고유하며, 식별하는 리소스가 더 이상 존재하지 않거나 사용할 수 없게 된 후에도 오랫동안 유지된다. (RFC 8141, 2017)

URC는 개념 단계를 넘어선 적이 없으며, 이후 Resource Description Framework와 같은 다른 기술로 대체되었다. (W3C/IETF, 2001) 2005년 IETF의 RFC 3986 문서부터 'Uniform Resource Name'과 'Uniform Resource Locator'라는 용어는 URI라는 포괄적인 용어로 통합되었다. 이는 W3C와 IETF가 2001년에 제시한 관점을 반영한 것이다. (W3C/IETF, 2001)

URI는 인터넷상의 리소스를 식별하거나 이름을 붙이는 데 사용되는 문자열 문자이다. URI는 많은 인터넷 프로토콜에서 정보 리소스를 참조하고 접근하는 데 사용된다. URI 체계에는 http 및 ftp 프로토콜과 수백 개의 다른 프로토콜이 포함된다.

현대적인 관점에서 모든 URI는 리소스를 식별하며, 그중 일부는 특정 프로토콜과 결합하여 리소스의 위치를 나타내는 '로케이터(locator)' 역할도 수행한다. 다른 URI들은 로케이터가 아니며 리소스의 이름이나 식별자로만 사용될 수 있다. 리소스는 이동할 수 있으므로, 특정 위치에 얽매이지 않는 식별자(이름)가 위치를 나타내는 식별자(로케이터)보다 시간이 지나도 고유성과 영속성을 유지할 가능성이 높다. 그러나 URI가 해석 가능한지 여부는 '이름' 또는 '로케이터'라고 불리는지와 관계없이 여러 운영 및 실제 세부 사항에 따라 달라진다. 현대적 관점에서 '이름(Name)'과 '로케이터(Locator)' 사이의 구분은 더 이상 명확하지 않다.

이러한 관점에 따라, Uniform Resource ''Names''(URN)와 Uniform Resource ''Locators''(URL)의 구분은 현재 공식적인 IETF 기술 표준에서는 더 이상 사용되지 않지만, URL이라는 용어는 여전히 널리 쓰이고 있다.

현재 'URN'이라는 용어는 http:, ftp: 등과 같은 여러 URI '체계(scheme)' 중 하나인 urn: 체계를 가리키는 데 주로 사용된다. urn: 체계를 사용하는 URI는 로케이터가 아니며, 특정 프로토콜이나 접속 방법과 연결될 필요가 없고 반드시 해석(resolve)될 필요도 없다. 대신, 고유성을 유지하고 오랫동안 동일한 리소스를 지속적으로 식별하도록 보장하는 절차에 따라 할당되어야 한다. urn:uuid:처럼 등록 기관 없이 식별자를 할당하는 네임스페이스도 있지만, 대부분은 그렇지 않다. 대표적인 URN 네임스페이스로는 국제 표준 도서 번호인 urn:isbn이 있다. 이러한 관점은 RFC 8141 (2017)에서도 이어진다.

tag:, info:(현재는 거의 사용되지 않음), ni:(RFC 6920, 2013)와 같은 다른 URI 체계들도 로케이터가 아니며 특정 해석이나 접속 프로토콜과 연결되지 않는다는 점에서 urn: 체계와 유사하다.

RFC 2141 (1997년 5월 발행)에서는 URN의 문법을 BNF로 다음과 같이 기술한다.



 ::= "urn:"  ":"

여기서, 는 '네임스페이스 식별자(Namespace Identifier)', 는 '네임스페이스 고유 문자열(Namespace Specific String)'을 의미한다. 맨 앞의 urn:은 소문자로 표기해야 한다. 네임스페이스 식별자(NID)는 네임스페이스 고유 문자열(NSS)을 해석하는 방법을 결정한다.

2. 4. URN과 URL의 비교

URN은 특정 리소스 자체를 고유하게 식별하는 이름이고, URL은 해당 리소스가 어디에 있는지 위치를 알려주는 주소와 같다. 이는 마치 사람의 이름(URN)과 그 사람의 집 주소(URL)에 비유할 수 있다. URN은 리소스가 무엇인지('무엇')를 정의하고, URL은 그 리소스를 어떻게 찾을 수 있는지('어디')를 알려준다.

예를 들어, 책마다 부여되는 고유한 ISBN은 URN의 한 형태로 볼 수 있다. ISBN(URN)을 알면 특정 책을 식별하고 그에 대해 이야기할 수 있지만, 실제로 그 책을 읽거나 구매하려면 책이 있는 구체적인 위치, 예를 들어 교보문고나 예스24 같은 온라인 서점의 해당 도서 페이지 주소(URL)나 집 책장의 위치(물리적 위치)를 알아야 한다.

이처럼 URN과 URL은 서로 다른 역할을 하지만 상호 보완적인 관계에 있다. 특정 RFC 문서를 예로 들면, "urn:ietf:rfc:3187"은 해당 문서를 식별하는 URN이고, "https://datatracker.ietf.org/doc/html/rfc3187.html"은 그 문서 파일이 실제로 위치한 URL이다. URN을 통해 어떤 문서인지 명확히 하고, URL을 통해 해당 문서에 접근할 수 있다.

원래 URN은 인터넷 정보 구조의 일부로 URL, URC와 함께 고안되었다. 초기 개념에 따르면, URN은 리소스가 사라지거나 옮겨지더라도 영구적으로 유지되는 위치 독립적인 식별자인 반면, URL은 HTTP나 FTP 같은 특정 프로토콜을 사용하여 리소스의 위치를 지정하는 방식이었다. 하지만 시간이 지나면서 URI라는 더 포괄적인 개념이 등장했고, 현재 인터넷 기술 표준에서는 URN과 URL의 구분을 공식적으로 사용하지는 않는다. 그럼에도 불구하고 개념적으로 URN은 리소스의 영구적인 식별자, URL은 리소스의 현재 위치를 나타내는 주소로 이해하는 것이 여전히 유용하다. 현재 'URN'은 urn:으로 시작하는 특정 URI 체계(scheme)를 가리키는 용어로 주로 사용되며, 이는 여전히 로케이터(locator)가 아닌 식별자로서의 특징을 가진다.

3. 문법

URN의 기본적인 문법 구조는 `'urn::'` 형태이다. 이는 RFC 2141에서 처음 정의되었다.

`'urn:'`: URN임을 나타내는 스킴이다. 대소문자를 구분하지 않지만, 소문자 사용이 권장된다.
``: 네임스페이스 식별자(Namespace Identifier)로, 어떤 종류의 자원을 식별하는지를 나타낸다. 문자, 숫자, 하이픈(`-`)으로 구성될 수 있으며, IANA에 등록되어 관리된다. ``는 ``의 해석 방식을 결정한다.
``: 네임스페이스 특정 문자열(Namespace Specific String)로, 해당 네임스페이스 내에서 특정 자원을 고유하게 식별하는 문자열이다. ``의 구체적인 문법과 해석 방식은 전적으로 ``에 의해 정의된 네임스페이스의 규칙에 따라 달라진다. ``에는 ASCII 문자와 숫자, 다양한 구두점 및 특수 문자가 포함될 수 있으며, 허용되지 않는 문자는 퍼센트 인코딩을 통해 표현될 수 있다.

URN 문법은 이후 RFC 3986 및 RFC 8141을 통해 확장된 바커스-나우르 표기법(EBNF)으로 더 상세하게 정의되었으며, 구문 다이어그램으로도 표현될 수 있다. 특히 2017년 RFC 8141 업데이트에서는 NSS 내 슬래시(`/`) 문자 사용 허용, 쿼리 컴포넌트(`?=`), 리졸버 컴포넌트(`?+`), 프래그먼트 컴포넌트(`#`) 등 문법적 확장이 이루어졌다. 상세한 문법 규칙과 구성 요소, 확장 문법에 대한 내용은 하위 섹션에서 자세히 다룬다.

3. 1. 배커스-나우르 표기법 (BNF)

RFC 2141(1997년 5월 발행)에서는 URN의 문법을 BNF 형식으로 다음과 같이 기술한다.

::= "urn:" ":"

여기서 는 "네임스페이스 식별자(Namespace Identifier)"이고, 는 "네임스페이스 고유 문자열(Namespace Specific String)"이다. 맨 앞의 "urn:"은 소문자여야 하며, 이 스킴 자체는 대소문자를 구분하지 않는다. 네임스페이스 식별자(NID)에 따라 네임스페이스 고유 문자열(NSS)의 해석 방법이 결정된다.

보다 상세한 문법은 EBNF로 다음과 같이 표현된다. 이는 RFC 3986과 RFC 8141을 따른다.

namestring = assigned-name

[ rq-components ]

[ "#" f-component ]

assigned-name = "urn" ":" NID ":" NSS

NID = (alphanum) 0*30(ldh) (alphanum)

ldh = alphanum / "-"

NSS = pchar *(pchar / "/")

rq-components = [ "?+" r-component ]

[ "?=" q-component ]

r-component = pchar *( pchar / "/" / "?" )

q-component = pchar *( pchar / "/" / "?" )

f-component = fragment

; general URI syntax rules (RFC3986)

fragment = *( pchar / "/" / "?" )

pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

pct-encoded = "%" HEXDIG HEXDIG

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

alphanum = ALPHA / DIGIT ; obsolete, usage is deprecated

구문 다이어그램 형태로 표현하면 다음과 같다.

는 네임스페이스 식별자로, 문자, 숫자, 하이픈(-)을 포함할 수 있으며, 길이는 최대 32자이다 (시작과 끝은 영숫자여야 함).
는 네임스페이스 특정 문자열로, NSS의 해석은 지정된 네임스페이스에 따라 달라진다. NSS는 ASCII 문자와 숫자, 많은 구두점 및 특수 문자를 포함할 수 있다. 금지된 ASCII 및 유니코드 문자는 퍼센트 인코딩을 통해 포함될 수 있다.

2017년 RFC 8141을 통해 URN 문법이 업데이트되었다. 주요 변경 사항은 다음과 같다.

슬래시 문자(/)가 NSS에서 허용되어, URN이 아닌 다른 식별자 시스템에서 슬래시를 포함하는 이름을 나타낼 수 있게 되었다.
q-component (?=)가 추가되어, 명명된 리소스에 매개변수를 전달할 수 있게 되었다.
r-component (?+)가 추가되어, 리졸버(resolver)에 매개변수를 전달할 수 있게 되었다. 다만, 이 기능은 추가 표준화를 통해 의미가 명확히 정의될 때까지 사용하지 않도록 권고된다.

3. 2. 구성 요소

URN의 문법은 일반적으로 `urn::` 형태로 표현된다.^[1]^[2] 각 구성 요소는 다음과 같은 의미와 규칙을 가진다.

`urn:` 스킴: URN임을 나타내는 필수적인 부분이다. URI 스킴과 마찬가지로 대소문자를 구분하지 않는다.^[3]^[4] 예를 들어, `urn:`, `URN:`, `UrN:` 등 모두 동일하게 인식된다. 하지만 RFC 2141에서는 소문자 `urn:` 사용을 권장한다.
`` (Namespace Identifier, 네임스페이스 식별자): 어떤 종류의 객체나 자원을 식별하는지를 나타내는 네임스페이스를 지정한다. ``는 문자, 숫자, 그리고 하이픈(`-`)으로 구성될 수 있으며, 길이는 일반적으로 1자 이상 32자 이하이다.^[3]^[4] ``는 IANA에 등록되어 관리되며, 각 네임스페이스는 고유한 규칙과 의미 체계를 가진다. 예를 들어, `isbn`은 국제 표준 도서 번호를 나타내는 네임스페이스이다. ``는 ``를 어떻게 해석해야 하는지를 결정하는 중요한 역할을 한다.
`` (Namespace Specific String, 네임스페이스 특정 문자열): 해당 네임스페이스 내에서 특정 자원을 고유하게 식별하는 문자열이다. ``의 구체적인 문법과 해석 방식은 전적으로 ``에 의해 정의된 네임스페이스의 규칙에 따라 달라진다.^[3]^[4] ``에는 ASCII 문자와 숫자, 그리고 다양한 구두점 및 특수 문자(`!`, `$`, `&`, `'`, `(`, `)`, `*`, `+`, `,`, `;`, `=`, `:`, `@`, `-`, `.`, `_`, `~`)가 포함될 수 있다. 만약 허용되지 않는 ASCII 문자나 유니코드 문자를 사용해야 할 경우, 퍼센트 인코딩 방식을 사용하여 표현할 수 있다.^[3]^[4] 2017년 RFC 8141 업데이트를 통해, 기존 식별자 시스템과의 호환성을 위해 슬래시(`/`) 문자도 `` 내에서 사용할 수 있게 되었다.^[4]

또한, 2017년 업데이트(RFC 8141)에서는 URN에 선택적으로 추가 정보를 포함할 수 있는 구성 요소들이 도입되었다.^[4]

q-component (`?=`): 명명된 리소스에 대한 쿼리 매개변수를 전달하기 위해 사용된다.
r-component (`?+`): URN 해석기(resolver)에 매개변수를 전달하기 위해 사용된다. 다만, 이 구성 요소의 구체적인 사용법은 아직 표준화가 더 진행되어야 한다.^[4]
f-component (`#`): 리소스 내의 특정 부분을 식별하는 프래그먼트(fragment) 식별자이다. 이는 일반적인 URI의 프래그먼트와 유사하게 작동한다.^[3]^[4]

이러한 구성 요소들을 통해 URN은 특정 네임스페이스 내에서 자원을 고유하게 식별하고, 필요에 따라 추가적인 정보를 전달하는 기능을 수행한다.

3. 3. 확장 문법 (RFC 8141)

2017년에 RFC 8141 표준이 발표되면서 URN의 문법이 확장되었다. 업데이트된 문법은 확장된 바커스-나우르 표기법(EBNF)으로 다음과 같이 정의된다.

namestring = assigned-name

[ rq-components ]

[ "#" f-component ]

assigned-name = "urn" ":" NID ":" NSS

NID = (alphanum) 0*30(ldh) (alphanum)

ldh = alphanum / "-"

NSS = pchar *(pchar / "/")

rq-components = [ "?+" r-component ]

[ "?=" q-component ]

r-component = pchar *( pchar / "/" / "?" )

q-component = pchar *( pchar / "/" / "?" )

f-component = fragment

; general URI syntax rules (RFC3986)

fragment = *( pchar / "/" / "?" )

pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

pct-encoded = "%" HEXDIG HEXDIG

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

alphanum = ALPHA / DIGIT ; obsolete, usage is deprecated

주요 변경 사항 및 추가된 요소는 다음과 같다.

NSS 내 슬래시(/) 허용: 기존에는 NSS(Namespace Specific String)에서 슬래시 문자가 허용되지 않았으나, RFC 8141 업데이트로 허용되었다. 이는 URN으로 표현하려는 식별자 자체가 슬래시를 포함하는 경우 (예: 파일 시스템 경로) 이를 그대로 유지할 수 있도록 하기 위함이다.
r-component (?+): URN 해석 과정에 관여하는 리졸버(resolver)에게 매개변수를 전달하기 위해 도입되었다. 예를 들어, 특정 리졸버 서비스의 주소를 지정하거나 해석 방식을 제어하는 데 사용될 수 있다. 하지만 RFC 8141에서는 이 요소의 구체적인 의미와 사용법이 추가적으로 표준화되기 전까지는 사용하지 말 것을 권고하고 있다.
q-component (?=): URN으로 식별되는 명명된 리소스(named resource) 자체에 매개변수를 전달하기 위해 추가되었다. 이는 웹 URI의 쿼리 문자열과 유사한 역할을 수행하며, 리소스의 특정 버전, 형식 또는 상태를 요청하는 데 사용될 수 있다.
f-component (#): 기존 URI 문법의 프래그먼트 식별자(fragment identifier)와 동일하다. URN이 식별하는 주 리소스 내의 특정 하위 부분(예: 문서의 특정 섹션)을 가리키는 데 사용된다.

기본적인 URN 구조 요소는 다음과 같다.

선행하는 스킴 urn:은 대소문자를 구분하지 않는다.
NID(Namespace Identifier)는 네임스페이스 식별자로, 문자, 숫자, 하이픈(-)을 포함할 수 있으며, 최대 32자 길이이다. (시작과 끝은 문자 또는 숫자여야 함)
NSS(Namespace Specific String)는 특정 네임스페이스 안에서 고유한 문자열이다. NSS의 해석 방식은 해당 NID가 정의하는 네임스페이스 규칙에 따라 달라진다. NSS는 ASCII 문자와 숫자, 그리고 다양한 구두점 및 특수 문자를 포함할 수 있다. URI 문법에서 직접 허용되지 않는 ASCII 문자나 유니코드 문자는 퍼센트 인코딩을 통해 포함될 수 있다.

4. 네임스페이스 (Namespaces)

URN 네임스페이스의 전역적인 고유성을 보장하기 위해, 해당 식별자(NID)는 IANA에 등록되어야 한다. 등록된 네임스페이스는 "정식" 또는 "비정식"으로 분류된다. 과거에는 "실험적 네임스페이스"에 대한 등록 예외가 있었으나, RFC 8141에 의해 폐지되었다.

4. 1. 공식 (Formal) 네임스페이스

약 60개 정도의 공식 URN 네임스페이스 식별자가 등록되어 있다. 이러한 네임스페이스는 인터넷 사용자가 해당 네임스페이스의 공표를 통해 혜택을 얻을 것으로 예상되는 경우 등록되며, 몇 가지 제약 사항을 따른다. 제약 사항은 다음과 같다.

이미 등록된 네임스페이스 식별자(NID)가 아니어야 한다.
`'urn-'`으로 시작하지 않아야 한다.
두 글자 이상이어야 한다.
XY가 두 개의 ASCII 문자의 조합일 때, `'XY-'`로 시작하지 않아야 한다.
`'x-'`로 시작하지 않아야 한다. ('실험적 네임스페이스' 관련).

4. 2. 비공식 (Informal) 네임스페이스

비공식 네임스페이스는 IANA에 등록되며, 식별자로는 IANA가 선착순으로 할당하는 일련의 숫자가 부여된다. 형식은 다음과 같다.

:"urn-"

비공식 네임스페이스는 완전한 URN 네임스페이스이며, 글로벌 등록 서비스에도 등록될 수 있다.

4. 3. 실험적 (Experimental) 네임스페이스 (폐지)

과거에는 URN 등록 요구 사항의 예외로 "실험적 네임스페이스"가 존재했다. 그러나 새로운 식별자 이름에 대한 "X-" 표기법이 폐지된 후, RFC 8141에서는 실험적 URN 네임스페이스를 폐지하고, 적절한 경우 urn:example 네임스페이스 사용을 선호한다고 밝혔다.

5. 예시

URN은 다양한 종류의 자원을 고유하게 식별하기 위해 사용된다. 예를 들어, 책을 식별하는 국제 표준 도서 번호, 시청각 자료를 식별하는 국제 표준 시청각 번호, 연속 간행물을 식별하는 국제 표준 연속 간행물 번호 등이 있다.

이 외에도 IETF의 기술 문서(RFC), MPEG-7 비디오 메타데이터 스키마, OID, UUID 등 다양한 표준 및 식별 체계에서 URN을 활용한다. 또한 상품 코드(GTIN), 위치 정보(GLN), 운송 컨테이너 코드(SSCC), 해상 관련 식별자(선박 번호, 항법 지원 식별자 등)처럼 특정 산업 분야에서도 널리 사용된다.^[1]^[2]

구체적인 URN 형식과 해당 내용은 아래 하위 섹션에서 자세히 살펴볼 수 있다.

5. 1. 국제 표준 식별자

URN 예시	설명
urn:isbn:0451450523	1968년 출판된 책 마지막 유니콘(The Last Unicorn)으로, 국제 표준 도서 번호로 식별된다.
urn:isan:0000-0000-2CEA-0000-1-0000-0000-Y	2002년 영화 스파이더맨(Spider-Man)으로, 국제 표준 시청각 번호로 식별된다.
urn:ISSN:0167-6423	과학 저널 Science of Computer Programming으로, 국제 표준 연속 간행물 번호로 식별된다.
urn:ietf:rfc:2648	IETF의 RFC 2648.
urn:mpeg:mpeg7:schema:2001	MPEG-7 비디오 메타데이터의 기본 네임스페이스 규칙.
urn:oid:2.16.840	OID는 미국에 해당한다.
urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66	버전 1 UUID.
urn:nbn:de:bvb:19-146642	문서에 대한 국가 서지 번호로, 국가(코드: de), 지역 네트워크(bvb = Bibliotheksverbund Bayern), 도서관 번호(19) 및 문서 번호를 나타낸다.
urn:lex:eu:council:directive:2010-03-09;2010-19-UE	제안된 Lex URN 네임스페이스를 사용하는 유럽 연합 지침.
urn:lsid:zoobank.org:pub:CDC8D258-8F57-41DC-B560-247E17D3DC8C	생명 과학 식별자로, [http://zoobank.org/urn:lsid:zoobank.org:pub:CDC8D258-8F57-41DC-B560-247E17D3DC8C]로 확인될 수 있다.
urn:epc:class:lgtin:4012345.012345.998877	로트/배치 번호가 있는 글로벌 무역 품목 번호. Tag Data Standard^[1](TDS)에 의해 정의되었다. EPC 식별 키에서 더 많은 예를 참조할 수 있다.
urn:epc:id:sgtin:0614141.112345.400	개별 일련 번호가 있는 글로벌 무역 품목 번호.
urn:epc:id:sscc:0614141.1234567890	일련 운송 컨테이너 코드.
urn:epc:id:sgln:0614141.12345.400	확장이 있는 글로벌 위치 번호.
urn:epc:id:bic:CSQU3054383	ISO 6346에 따른 BIC 복합 운송 컨테이너 코드.
urn:epc:id:imovn:9176187	해양 선박의 IMO 선박 번호.
urn:epc:id:gdti:0614141.12345.400	문서 인스턴스의 글로벌 문서 유형 식별자.
urn:mrn:iala:aton:us:1234.5	[https://www.iala-aism.org/product/g1143-unique-identifiers-for-maritime-resources-2/ 해상 항법 지원] 식별자.
urn:mrn:iala:vts:ca:ecareg	선박 교통 서비스 식별자.
urn:mrn:iala:wwy:us:atl:chba:potri	[https://www.iala-aism.org/product/g1143-unique-identifiers-for-maritime-resources-2/ 수로] 식별자.
urn:mrn:iala:pub:g1143	[https://www.iala-aism.org/ IALA] 간행물 식별자.
urn:microsoft:adfs:claimsxray	페더레이션 ID 식별자; 이 예는 Claims X-Ray^[2]에서 가져왔다.
urn:eic:10X1001A1001A450	유럽 전력 시스템 운영자 네트워크 (ENTSO-E)는 에너지 식별 코드로 식별된다.
urn:uci:I001+SBSi-B10000083052	SBS 방송의 드라마 [http://uci.or.kr/I001+SBSi-B10000083052 Snow Flower]를 가리키는 UCI ID ([https://tools.ietf.org/html/rfc4179 RFC 4179]).

5. 2. IETF RFC

`urn:ietf:rfc:2648`은 IETF의 RFC 2648 문서를 식별하는 URN이다.

5. 3. MPEG-7

`urn:mpeg:mpeg7:schema:2001`은 MPEG-7 비디오 메타데이터의 기본 네임스페이스 규칙을 나타내는 URN이다.

5. 4. OID

`urn:oid:2.16.840`은 미국을 나타내는 OID에 해당하는 URN이다.

5. 5. UUID

`urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66`는 버전 1 UUID를 사용한 URN의 예시이다.

5. 6. 한국 관련 URN 예시

;urn:uci:I001+SBSi-B10000083052

: SBS 방송의 드라마 [http://uci.or.kr/I001+SBSi-B10000083052 Snow Flower]를 가리키는 UCI ID. 이는 [https://tools.ietf.org/html/rfc4179 RFC 4179]에 정의되어 있다.

5. 7. 기타 URN 예시

wikitext

URN	해당 내용
`urn:isbn:0451450523`	1968년 출판된 책 마지막 유니콘(The Last Unicorn)으로, 국제 표준 도서 번호로 식별된다.
`urn:isan:0000-0000-2CEA-0000-1-0000-0000-Y`	2002년 영화 스파이더맨(Spider-Man)으로, 국제 표준 시청각 번호로 식별된다.
`urn:ISSN:0167-6423`	과학 저널 Science of Computer Programming으로, 국제 표준 연속 간행물 번호로 식별된다.
`urn:ietf:rfc:2648`	IETF의 RFC 2648.
`urn:mpeg:mpeg7:schema:2001`	MPEG-7 비디오 메타데이터의 기본 네임스페이스 규칙.
`urn:oid:2.16.840`	OID는 미국에 해당한다.
`urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66`	버전 1 UUID.
`urn:nbn:de:bvb:19-146642`	문서에 대한 국가 서지 번호로, 국가(코드: `de`), 지역 네트워크(`bvb` = Bibliotheksverbund Bayern), 도서관 번호(19) 및 문서 번호를 나타낸다.
`urn:lex:eu:council:directive:2010-03-09;2010-19-UE`	제안된 Lex URN 네임스페이스를 사용하는 유럽 연합 지침.
`urn:lsid:zoobank.org:pub:CDC8D258-8F57-41DC-B560-247E17D3DC8C`	생명 과학 식별자로, http://zoobank.org/urn:lsid:zoobank.org:pub:CDC8D258-8F57-41DC-B560-247E17D3DC8C로 확인될 수 있다.
`urn:epc:class:lgtin:4012345.012345.998877`	로트/배치 번호가 있는 글로벌 무역 품목 번호. Tag Data Standard^[1](TDS)에 의해 정의되었다. EPC 식별 키에서 더 많은 예를 참조할 수 있다.
`urn:epc:id:sgtin:0614141.112345.400`	개별 일련 번호가 있는 글로벌 무역 품목 번호.
`urn:epc:id:sscc:0614141.1234567890`	일련 운송 컨테이너 코드.
`urn:epc:id:sgln:0614141.12345.400`	확장이 있는 글로벌 위치 번호.
`urn:epc:id:bic:CSQU3054383`	ISO 6346에 따른 BIC 복합 운송 컨테이너 코드.
`urn:epc:id:imovn:9176187`	해양 선박의 IMO 선박 번호.
`urn:epc:id:gdti:0614141.12345.400`	문서 인스턴스의 글로벌 문서 유형 식별자.
`urn:mrn:iala:aton:us:1234.5`	[https://www.iala-aism.org/product/g1143-unique-identifiers-for-maritime-resources-2/ 해상 항법 지원] 식별자.
`urn:mrn:iala:vts:ca:ecareg`	선박 교통 서비스 식별자.
`urn:mrn:iala:wwy:us:atl:chba:potri`	[https://www.iala-aism.org/product/g1143-unique-identifiers-for-maritime-resources-2/ 수로] 식별자.
`urn:mrn:iala:pub:g1143`	[https://www.iala-aism.org/ IALA] 간행물 식별자.
`urn:microsoft:adfs:claimsxray`	페더레이션 ID 식별자; 이 예는 Claims X-Ray^[2]에서 가져왔다.
`urn:eic:10X1001A1001A450`	유럽 전력 시스템 운영자 네트워크 (ENTSO-E)는 에너지 식별 코드로 식별된다.

참조

_[1] 웹사이트 EPC Tag Data Standard, version 1.13 https://www.gs1.org/[...] GS1 2021-03-07
_[2] 웹사이트 Claims X-Ray AD FS Help https://adfshelp.mic[...]
_[3] 사전 URN https://kotobank.jp/[...] 大辞泉
_[4] 웹사이트 RFC1630(Universal Resource Identifiers in WWW) http://srgia.com/doc[...] 2019-03-24

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com