Golden Observation｜RSS3 프로젝트 구현의 기반: RFC3986 Uniform Resource Identifier

RSS3는 web3 분야에서 유망한 프로젝트로 꼽히는데, 최근에 web3 application을 경험하면서 web3의 핵심 요소에 대한 정의 패러다임을 찾으려고 노력하다가 RSS3를 찾던 중 내가 찾던 프로토콜을 발견하게 되었다. 데이터 사양 프로토콜로 정의할 수 있으며 프로토콜은 RFC3986 Uniform Resource Identifier이며 일반 문법으로도 이해할 수 있습니다.

문서의 원문이 3w 단어 이상이라 읽기가 쉽지 않아 문서에서 많은 삭제와 수정을 가했고, web3의 데이터 형식을 이해하기 위해 예제를 만들었습니다.

알아야 할 것은 이 규격이 인터넷 정보 표준이고 오래전부터 적용되어 왔다는 것입니다.

RSS3

RSS3는 Web3에서 효율적이고 분산된 정보 배포를 지원하도록 설계된 개방형 정보 신디케이션 프로토콜입니다. 광범위한 호환성 논리 없이도 다른 소비자가 통합된 형식으로 다양한 콘텐츠 소스에 쉽게 접근할 수 있도록 정보 제공 및 커뮤니케이션을 위한 형식을 정의합니다.

RSS3 프로토콜에서 정보는 구성 파일, 링크, 자산, 주석의 네 가지 유형으로 나뉩니다.

RSS3 응용 프로그램은 RSS3SDK를 사용하여 RSS3 프로토콜에 정의된 형식으로 데이터에 액세스하고 게시합니다. RSS3 SDK는 RSS3 네트워크에서 데이터를 획득하고 RSS3에서 지원하는 네트워크에 데이터를 게시합니다. RSS3 네트워크는 다양한 RSS3 지원 네트워크에서 데이터를 크롤링하고 데이터를 캐시합니다. 스스로에게 고효율 데이터베이스에서 검색 기능을 제공하기 위해 인공 지능 추천 알고리즘을 적용하는 등 일부 전처리를 수행합니다.

이러한 제품 설계에서는 네트워크 전송 데이터의 일부 세부 사항을 정의함으로써 가장 독창적인 데이터 사양이 완성되며, 일단 데이터가 정의되면 기본적인 데이터 가용성 부분이 완성됩니다. 상위 계층 응용 프로그램을 보다 쉽게 구현할 수 있습니다. 이 프로토콜을 살펴보겠습니다: RFC3986 Uniform Resource Identifier. 콘텐츠를 삭제 및 수정한 후 저자는 인터넷 데이터 처리에 대한 간략한 이해를 위해 일부 관련 요구 사항을 충족하기 위해 노력합니다.

RFC3986: 통일 자원 식별자

이 사양은 RFC2396[RFC2396], RFC1808[RFC1808] 및 RFC1738[RFC1738]에서 파생되었으며 호스트 구문의 IPv6 리터럴에 대한 업데이트(및 수정)도 포함합니다.

URI(Uniform Resource Identifier)는 요약을 식별하거나 물리적 리소스를 나타내는 간결한 문자 시퀀스로, 리소스를 식별하기 위한 간단하고 확장 가능한 방법을 제공합니다. 이 사양은 URI 사용에 대한 지침 및 보안 고려 사항뿐만 아니라 일반 URI 구문 및 URI 참조의 절차적 해결을 상대 형식으로 정의합니다.

URI 문법은 구문 상위 집합을 정의합니다. 유효 URI는 공통 구성 요소 구문 분석을 허용하여 특정 체계에서 필요하지 않은 경우 URI를 사용하여 모든 가능한 식별자를 참조할 수 있도록 합니다. 이 사양은 URI 생성 문법을 정의하지 않습니다.

URI(Uniform Resource Identifier) 의미 체계는 World Wide Web Global Information Initiative에서 도입한 개념에서 파생되었으며, 구문은 리소스 로케이터[RFC1736] 및 "인터넷 기능"에 나열된 통일 리소스 이름 기능의 요구 사항을 충족하도록 설계되었습니다. 권장 사항" [RFC1737] .

이 문서는 [RFC2396]을 폐기하고 "Uniform Resource Locators" [RFC1738] 및 "Relative Uniform Resource Locators" [RFC1808]를 병합하여 모든 URI에 대한 단일 공통 구문을 정의합니다. IPv6 주소에 대한 구문을 도입한 폐기된 [RFC2732].

URI의 특징

일률

해당 리소스에 액세스하는 데 사용되는 메커니즘이 다를 수 있지만 다른 유형의 리소스가 동일한 컨텍스트에서 동일한 리소스 식별자를 사용할 수 있습니다.

공통 문장의 통합된 의미론적 해석을 통해 다양한 유형의 리소스 식별자에 대한 동의를 완료할 수 있습니다.

기존 식별자가 사용되는 방식을 방해하지 않고 새로운 유형의 리소스 식별자를 도입할 수 있습니다.

이를 통해 다양한 컨텍스트에서 식별자를 재사용할 수 있으므로 새로운 응용 프로그램이나 프로토콜이 기존의 크고 널리 사용되는 리소스 식별자 세트를 활용할 수 있습니다.

자원

"리소스"라는 용어는 일반적인 의미에서 URI로 식별할 수 있는 모든 콘텐츠를 나타냅니다. 익숙한 예로는 전자 문서, 이미지, 정보 소스, 서비스 및 기타 리소스 모음이 있습니다. 리소스는 반드시 인터넷을 통해 액세스할 수 있는 것은 아닙니다. 마찬가지로 추상화는 수학 방정식의 연산자 및 피연산자, 관계 유형(예: "부모" 또는 "직원") 또는 숫자 값(예: 0, 1, 무한대)과 같은 리소스가 될 수 있습니다.

식별자

식별자는 원하는 정보를 해당 범위 내의 다른 모든 것과 구별하는 콘텐츠 인증 프로세스를 구현합니다. 그러나 이러한 정의를 식별자 정의 또는 참조된 콘텐츠의 ID를 구현하는 것으로 착각해서는 안 됩니다. 많은 경우에 URI는 리소스를 나타내기 위해 사용되지만 리소스에 액세스할 수 있음을 나타내기 위해 사용되지는 않습니다. 마찬가지로, 식별된 "a" 리소스는 본질적으로 단일하지 않을 수 있습니다(예: 리소스는 명명된 집합 또는 시간 경과에 따른 매핑일 수 있음).

URI는 전역 범위를 가지며 어떤 경우에도 일관성 있게 컨텍스트를 해석하는 데 사용됩니다. 이 해석의 결과는 최종 사용자의 컨텍스트에 상대적일 수 있습니다. 예를 들어 "http://localhost/"는 "localhost"에 해당하는 네트워크 인터페이스가 다른 사용자일 수 있지만 참조된 모든 사용자에 대해 동일한 해석을 갖습니다. 즉, 해석은 액세스와 무관합니다.

일반 문법

URI 구문은 각 체계의 사양이 해당 체계를 사용하는 식별자의 구문과 의미 체계를 추가로 제한할 수 있는 연합되고 확장 가능한 이름 지정 시스템입니다.

URI 참조는 URI 참조 형식을 사용하는 프로토콜 및 데이터가 아직 정의되지 않은 스키마를 포함하여 이 사양에서 허용하는 전체 구문 범위를 참조하여 URI를 정의할 수 있는 독립적인 확인 메커니즘을 사용합니다.

일반 URI 문법에 대한 구문 분석기는 모든 URI 참조를 주요 구성 요소로 구문 분석할 수 있습니다. 계획이 확정된 후 추가로

구성 요소에서 시나리오별 구문 분석을 수행할 수 있습니다. 즉, URI 일반 구문은 모든 URI 구문의 상위 집합입니다.

URI, URL 및 URN

URI는 로케이터, 이름 또는 둘 다로 추가 분류될 수 있습니다.

"Uniform Resource Locator"(URL)는 URI의 하위 집합을 나타냅니다. 리소스를 식별하는 것 외에도 액세스 메커니즘(예: 네트워크 "위치")을 설명하여 리소스를 찾는 방법도 제공합니다.

"Uniform Resource Name"(URN)은 리소스가 더 이상 존재하지 않거나 사용할 수 없게 된 후에도 전역적으로 고유한 다른 URI를 나타내는 데 사용되었습니다.

URI는 매우 제한된 세트(라틴 문자, 숫자 및 일부 특수 문자)에서 가져옵니다.

URI는 다양한 방식으로 표현될 수 있습니다(예: 종이의 잉크, 화면의 픽셀 또는 일련의 문자 인코딩 옥텟). URI의 해석은 사용된 문자에 따라 달라집니다. 로컬 또는 지역 환경에서 기술이 발전함에 따라 사용자는 더 다양한 문자를 사용할 수 있습니다.

인식과 상호 작용의 분리

URI에 대한 일반적인 오해는 URI가 액세스 가능한 리소스를 참조하는 데만 사용된다는 것입니다. URI 자체는 인증만 제공하며 리소스 힌트에 대한 URI 액세스의 존재를 보장하지 않습니다. 대신 관련 URI 참조는 데이터 형식 속성 또는 자연어 텍스트와 같은 프로토콜 요소로 정의됩니다.

URI가 주어지면 시스템은 리소스에 대해 "액세스", "업데이트", "바꾸기" 또는 "속성 찾기"와 같은 단어로 특징지어지는 다양한 작업을 수행하려고 시도할 수 있습니다. 이러한 작업은 URI를 사용하는 프로토콜에 의해 정의됩니다.

계층적 식별자

URI 구문은 왼쪽에서 오른쪽으로 내림차순으로 구성 요소를 사용하여 계층적으로 구성됩니다.

일반 구문은 슬래시("/"), 물음표("?") 및 숫자 기호("#") 문자를 사용하여 이 클래스의 읽을 수 있는 식별자가 일관된다는 점을 제외하고 일반 파서의 계층적 해석에 중요한 구성 요소를 구분합니다. 구문, 이름 지정 체계 전반에 걸친 계층 구조의 통합 표현을 통해 체계 독립적인 참조를 해당 계층 구조와 관련하여 만들 수 있습니다.

일반적으로 문서의 집합 또는 "트리"는 공통 목적을 수행하도록 구성되었으며 이러한 문서의 대부분의 URI 참조는 트리 외부가 아닌 트리 내부의 리소스를 가리킵니다. 특정 위치의 설명서 사이트는 원격 사이트의 리소스보다 해당 사이트의 다른 리소스를 참조할 가능성이 더 큽니다. URI에 대한 참조를 통해 문서 트리 부분이 해당 위치 및 액세스 체계와 독립적일 수 있습니다.

문법 기호

다음 핵심 ABNF 구문 규칙을 포함하여 ABNF [RFC2234] 표기법 사용:

ALPHA(문자), CR(캐리지 리턴), DIGIT(십진수), DQUOTE(큰따옴표), HEXDIG(16진수), LF(줄 바꿈), SP(공백) 등

URI 구문은 리소스를 일련의 문자로 식별하기 위해 데이터를 인코딩하는 방법을 제공합니다. 차례로 URI 문자는 종종 전송 또는 표시를 위해 옥텟으로 인코딩됩니다.

ABNF 표기법은 터미널 값을 US-ASCII 코드 문자 세트[ASCII]를 기반으로 하는 음수가 아닌 정수(코드 포인트)로 정의합니다. URI는 일련의 문자이기 때문에 URI 구문을 이해하려면 해당 관계를 뒤집어야 합니다. 따라서 ABNF에서 사용하는 정수 값을 US-ASCII 대응 항목으로 다시 매핑하여 구문 규칙을 완성해야 합니다.

예약 문자

URI는 구성 요소와 하위 구성 요소를 구분하는 "예약된" 문자로 구성됩니다.

예약 문자의 목적은 구분 기호를 URI의 다른 데이터와 구별하는 문자 집합을 제공하는 것입니다. 예약 문자의 하위 집합(gen-delims)은 일반 URI 구성 요소의 구분 기호로 사용됩니다. 구성 요소에 대한 ABNF 문법 규칙은 예약된 또는 gen-delims를 직접 명명하지 않고 대신 각 문법 규칙은 해당 구성 요소 내에서 허용되는 문자(예: 구분되지 않음)를 나열하며 다른 하위 구성 요소는 URI 스키마 정의로 지정할 수 있습니다.

예약 문자 없음

대문자와 소문자, 십진수, 하이픈, 마침표, 밑줄 및 물결표를 포함하여 URI에서 허용되지만 예약되지 않은 문자입니다.

예약되지 않음=ALPHA/DIGIT/"-"/"."/"_"/"~"

다른 URI를 예약되지 않은 문자로 대체하지만 해당 퍼센트로 인코딩된 US-ASCII 옥텟은 동일합니다. 동일한 리소스를 식별합니다. 일관성을 위해 ALPHA 범위의 백분율로 인코딩된 옥텟(%41-%5A 및 %61-%7A), DIGIT(%30-%39), 하이픈(%2D), 마침표(%2E), URI를 생성해서는 안 됩니다. 밑줄(%5F) 또는 물결표(%7E) 생산자는 URI에서 발견될 때 URI 노멀라이저의 예약되지 않은 해당 문자로 디코딩되어야 합니다.

식별 데이터

URI 문자는 식별된 시스템 외부 인터페이스로서 각 URI에 대한 식별 데이터 구성 요소를 제공합니다.

URI 생성 및 전송: 로컬 이름 및 데이터 인코딩, 공용 인터페이스 인코딩, URI 문자 인코딩, 데이터 형식 인코딩 및 프로토콜 인코딩.

로컬 이름(예: 파일 시스템 이름)은 로컬 문자 인코딩으로 저장됩니다. URI 생성 응용 프로그램(예: 원본 서버)은 일반적으로 의미 있는 이름을 생성하기 위한 기반으로 로컬 인코딩을 사용합니다. URI 생성자는 로컬 인코딩을 공용 인터페이스에 적합한 인코딩으로 변환한 다음 공용 인터페이스 인코딩을 제한된 URI 문자 세트(예약됨, 예약되지 않음 및 퍼센트 인코딩됨)로 변환합니다.

차례로 이러한 문자는 문서 문자 집합과 같은 데이터 형식에서 참조로 사용하기 위해 옥텟으로 인코딩되며, 이는 종종 인터넷 프로토콜을 통한 전송을 위해 인코딩됩니다.

경우에 따라 URI 구성 요소와 그것이 나타내는 데이터를 식별하는 것이 문자 인코딩 변환보다 훨씬 간단하지 않습니다.

문법적 구성요소

일반 URI 구문은 체계, 권한, 경로, 쿼리 및 조각의 계층적 시퀀스로 구성됩니다.

경로가 비어 있을 수 있지만(문자 없음) 구성표 및 경로 구성 요소가 필요합니다. 권한이 있는 경우 경로는 비어 있거나 슬래시("/") 문자로 시작해야 합니다. 권한이 없는 경우 경로는 두 개의 슬래시 문자("//")로 시작하면 안 됩니다. 이러한 제한으로 인해 5개의 서로 다른 ABNF 경로 규칙이 생성되며 그 중 하나만 주어진 URI 참조와 일치합니다.

계획

모든 URI는 해당 체계 내에서 식별자를 할당하기 위한 사양을 참조하는 체계 이름으로 시작합니다.

체계 이름은 문자로 시작하여 문자, 숫자, 더하기 기호("+"), 마침표(".") 또는 하이픈("-")의 조합이 뒤따르는 일련의 문자로 구성됩니다.

구성표=알파*(알파/숫자/"+"/"-"/".")

권한

많은 URI 체계에는 이름 지정을 위한 계층적 요소 권한이 포함되어 있으므로 관리는 나머지 URI에 의해 해당 권한에 위임됩니다. 일반 구문은 일반 레지스트리 기반 이름 또는 서버 주소와 선택적으로 포트 및 사용자 정보를 제공합니다.

권한 구성 요소 앞에는 이중 슬래시("//")가 있고 그 뒤에는 슬래시("/"), 물음표("?") 또는 숫자 끝("#") 문자가 옵니다. URI의 끝.

권한 = [사용자 정보 "@"]호스트[":"포트]

주인

기관의 호스트 하위 구성 요소는 대괄호로 묶인 IP 리터럴로 식별됩니다. 대부분의 경우 호스트 구문은 단순히 DNS에서 기존 레지스트리를 만들고 배포하는 데 사용되므로 다른 레지스트리를 배포하는 비용 없이 전역적으로 고유한 이름을 얻습니다.

호스트=IP 필드/IPv4address/reg-name

IP 필드 = "["(IPv6Address/IPvFuture)"]"

IPvFuture="v"1*HEXDIG"."1*(예약되지 않은/하위 구분 기호/":")

문의

쿼리 구성 요소에는 비계층적 데이터와 URI 체계 및 이름 지정 권한 범위 내에서 리소스를 식별하는 경로 구성 요소의 데이터가 포함됩니다.

쿼리 구성 요소는 물음표("?") 문자로 표시되고 숫자 기호("#") 문자로 끝납니다.

쿼리=*(pchar/"/"/"?")

용법

응용 프로그램이 URI를 참조할 때 "URI" 구문 규칙에 의해 정의된 전체 참조 형식을 항상 사용하지는 않습니다. 공간을 절약하고 계층적 지역성을 활용하는 많은 인터넷 프로토콜 요소 및 미디어 유형 형식은 축약된 URI를 허용하는 반면 다른 형식은 구문을 특정 형식의 URI로 제한합니다.

기본 URI 빌드

프래그먼트 전용 참조 외에도 기본 URI가 필요한 것으로 알려져 있습니다. 확인자는 기본 URI를 설정해야 합니다. 기본 URI는 <absolute-URI>의 구문 규칙을 준수해야 합니다.

기본 URI는 네 가지 방법 중 하나로 설정할 수 있습니다.

콘텐츠에 포함된 기본 URI

엔터티의 기본 URI를 캡슐화합니다.

엔터티를 검색하는 데 사용되는 URI

기본 기본 URI(응용 프로그램에 따라 다름)

정규화 및 비교

URI에 대한 가장 일반적인 작업은 간단한 비교입니다. 즉, 두 URI가 URI를 사용하지 않고 해당 리소스에 동일하게 액세스하는지 여부를 결정하는 것입니다. 광범위한 정규화는 일반적으로 URI를 비교하기 전에 수행됩니다. URI 비교는 일부 특정 목적을 위해 수행됩니다.

등가

URI는 리소스를 식별하기 위해 존재하므로 동일한 리소스를 식별할 때 동일한 것으로 간주됩니다. 그러나 이러한 동등성에 대한 정의는 두 자원에 대한 완전한 지식이나 통제력이 없는 한 두 자원을 비교할 방법이 없기 때문에 실용적이지 않습니다.

두 URI가 동일한 것으로 결정될 수 있더라도 두 URI가 서로 다른 리소스를 식별하는지 확인하기에는 URI 비교가 충분하지 않습니다.

구문 기반 정규화

구문 기반 정규화에는 다음과 같은 사례 정규화, 퍼센트 인코딩 정규화 및 도트 세그먼트 제거 기술이 포함됩니다.

안전 예방 조치

URI 자체는 보안 위협이 되지 않습니다. 그러나 URI는 종종 액세스를 위한 간결한 지침 집합을 제공하는 데 사용됩니다.

웹 리소스의 경우 URI의 데이터를 올바르게 해석하여 실수로 데이터에 액세스하지 않도록 하고 공개해서는 안 되는 데이터 텍스트를 포함하지 않도록 주의해야 합니다.

민감한 정보

URI 생산자는 사용자 이름을 포함하거나 비밀로 유지하려는 비밀번호를 제공해서는 안 됩니다. URI는 종종 브라우저에 표시되고 일반 텍스트 책갈피에 저장되며 사용자 에이전트 기록 및 중간 응용 프로그램(프록시)에 의해 표시됩니다.

시맨틱 공격

userinfo 하위 구성 요소는 거의 사용되지 않기 때문에 권한 구성 요소에 나타나는 호스트는 사용자가 신뢰하도록 오도하는 URI를 구성하는 데 사용될 수 있습니다.

ftp://cnn.example.com&[email protected]/top_story.htm

호스트가 실제로는 '10.0.0.1'인데 사용자가 호스트가 'cnn.example.com'이라고 가정할 수 있습니다. 오해의 소지가 있는 URI는 사용자의 선입견을 공격하는 사용자에 대한 공격일 수 있습니다. 소프트웨어 자체와 관련하여 이러한 공격은 URI의 개별 구성 요소를 구분하여 피할 수 있습니다.