SPECIFICATION

제1장 개요와 프로토콜 위치

본 장은 DTP의 프로토콜 범위(§1.1), 프로토콜 위치(§1.2), CAP와의 관계(§1.3), 설계 목표(§1.4), 주종 모델(§1.5), 일치성 수준(§1.6)을 정의하며, §1.7 「버전 관리와 호환성」에서 DTP의 버전 관리 규칙을 규범적 형식으로 제시한다——이로써 본 프로토콜은 자체 버전 설명을 갖추어, 표준 구현자가 외부 문서를 검색하지 않고 직접 참조할 수 있다.

1.1 프로토콜 범위

데이터 터널 프로토콜(DTP)은 iFay 생태계에서 단말 장치와 Fay 인스턴스 간 양방향 데이터 전송을 담당하는 응용 계층 프로토콜이어야 한다.

DTP는 다음 두 가지 핵심 데이터 흐름을 구현해야 한다:

데이터 수집(Data Collection): 단말(Slave)에서 Fay(Master)로 흐르며, 단말이 생성한 데이터를 iFay의 Personal Data Heap에 영속화하는 데 사용한다.
데이터 주입(Data Injection): Fay(Master)에서 단말(Slave)로 흐르며, iFay에 의해 필터링된 최소화 데이터셋을 단말 애플리케이션에 일시적으로 제공하는 데 사용한다.

DTP는 다른 용도로 사용해서는 안 된다.

1.2 프로토콜 위치

DTP는 BLE, RTSP, WebSocket, TCP를 포함한(이에 국한되지 않는) 기존 전송 프로토콜 위에서 동작하는 응용 계층 프로토콜로 운영되어야 한다.

DTP는 Transport_Adapter 추상 계층을 통해 구체적인 전송 프로토콜과 상호 작용해야 한다(제3.4절 참조). DTP 코어는 어떠한 구체적인 전송 프로토콜의 구현 세부사항에도 의존해서는 안 된다.

1.3 CAP와의 관계

DTP는 제어 권한 부여 프로토콜(CAP)과 협력하여 동작해야 하며, 다음 분담 구조를 따른다:

CAP 는 연결 권한 부여, 신원 검증 및 키 교환을 담당한다.
DTP 는 협상 기반 데이터 흐름 전송을 담당한다.

DTP 구현은 CAP가 신원 검증과 키 교환을 완료한 후에만 데이터 전송을 시작해야 한다. CAP가 아직 준비되지 않은 경우, DTP 구현은 데이터 전송을 거부하고 KEY_NOT_READY 오류(오류 코드 2002, 제9장 참조)를 반환해야 한다.

1.4 설계 목표

DTP 구현은 다음 설계 목표를 충족해야 한다:

목표	규범적 요구사항
전송 비의존성	DTP 코어 로직은 구체적인 전송 프로토콜과 분리되어야 한다
협상 우선	모든 데이터 전송은 달성된 약정(Agreement)에 기반해야 한다
데이터 주권	주단은 데이터 흐름에 대한 최종 결정권을 가져야 한다
종단 간 암호화	페이로드(Payload)는 암호화하여 전송해야 한다
컨텍스트 보전	각 데이터 조각은 구조화된 컨텍스트 메타데이터를 포함해야 한다
복구 가능성	구현은 시퀀스 번호 기반의 재개(resume) 메커니즘을 지원해야 한다

1.5 주종 모델

DTP는 다음 두 가지 역할을 구분해야 한다:

주단(Master): 자연인 사용자 또는 Fay(iFay / coFay). 데이터 수집 발의 권한과 데이터 주입 결정 권한을 가져야 한다.
종단(Slave): 소프트웨어 또는 하드웨어 단말. 데이터 주입 신청만 발의할 수 있으며, 데이터 수집 요청을 발의해서는 안 된다.

DTP 구현은 다음 제약을 강제해야 한다:

임의의 시점에 하나의 종단은 두 개 이상의 Fay에 의해 동시에 제어자(Controller)로 점유되어서는 안 된다.
제어자는 다른 Fay를 관찰자(Observer)로 초대할 수 있다.
관찰자는 요청을 발의하거나 약정을 수정해서는 안 되며, 데이터 흐름의 읽기 전용 사본만 수신할 수 있어야 한다.
주단이 데이터 수집 요청을 발의할 때 종단은 이를 수락해야 한다(권장). 종단은 거부할 수 있으나, 거부 시에는 컴플라이언스 사유를 첨부해야 한다(제5.3.1절 참조).
종단이 데이터 주입 신청을 발의할 때 주단은 완전한 결정권을 가져야 하며, 수락하거나 거부하거나 대안을 제시할 수 있다.

1.6 일치성 수준

구현은 자신의 일치성 수준을 선언해야 한다:

완전 일치(Full Conformance): 모든 MUST(필수) 와 SHOULD(권장) 규칙을 충족하는 구현.
코어 일치(Core Conformance): 모든 MUST(필수) 규칙을 충족하지만 일부 SHOULD(권장) 규칙은 충족하지 않을 수 있는 구현.
불일치(Non-Conformance): 어떤 MUST(필수) 규칙을 충족하지 않는 구현. DTP 구현으로 선언된 구현은 이 상태에 있어서는 안 된다.

1.7 버전 관리와 호환성(Version Management & Compatibility)

본 절은 규범적(Normative)이다. 본 절은 DTP 버전 관리 규칙의 **유일한 권위 있는 출처(Single Source of Truth)**이다. 본문의 다른 위치(제10장 「버전 관리」 및 변경 로그 포함, 존재하는 경우)에서 버전 규칙을 언급하는 모든 부분은 본 절을 따라야 하며, 본 절이 규정한 규칙을 재정의해서는 안 된다.

본 절은 다음 고정된 순서로 구성된다: 세 개의 직교 버전 축(§1.7.1) → MAJOR.MINOR 의미와 변경 판정(§1.7.2) → 버전 협상과 호환성 규칙(§1.7.3) → 편집 판차와 정오(§1.7.4) → 버전 번호 배치표와 구현자 유의사항(§1.7.5).

1.7.1 세 개의 직교 버전 축

DTP의 버전 정보는 서로 직교하는 세 개의 축을 따라 독립적으로 관리되어야 한다. 이 세 축은 단일 버전 번호로 병합해서는 안 된다. 각 축은 독립적인 값 공간, 기록 위치, 진화 규칙을 가지며, 한 축의 변경이 다른 두 축의 변경을 강제해서는 안 된다(직교성의 관측 가능한 정의).

축	의미	값 공간	기록 위치	와이어 포맷에 진입하는가?
프로토콜 버전(Protocol Version)	상호운용 계약	`dtp/MAJOR.MINOR`(2단계, PATCH 없음; `MAJOR`, `MINOR` 모두 음이 아닌 정수)	프레임 헤더 `protocolVersion` 필드, schema 파일명	예
문서 상태(Document Status)	문서 생명주기	열거형 `Draft / Final / Deprecated / Obsolete`(임의의 시점에 정확히 하나의 값)	front matter의 `status` 필드	아니오
편집 판차(Editorial Edition)	정오와 명확화	배포 일자로 고정되는 `YYYY-MM-DD`(예: `2025-10-25`)	front matter의 `date` 필드와 배포 디렉터리명	아니오

문서 상태와 디렉터리에 관한 핵심 제약(완전한 디렉터리 규약과 확정 거버넌스 흐름은 제10장에 있으며, 그 규칙 앵커는 본 절을 기준으로 한다):

문서 상태는 front matter 마커여야 하며, 파일 경로나 디렉터리명에 인코딩해서는 안 된다.
어떤 배포 판차가 현재 Final인지 Deprecated / Obsolete인지는 오직 그 파일의 status 필드로 결정되며, 디렉터리명으로 추론해서는 안 된다.

1.7.2 `MAJOR.MINOR` 의미와 변경 판정

MAJOR(메이저 버전)

MAJOR는 상호운용을 깨뜨리는 변경에 사용한다. 판정 기준: MAJOR.0 구버전을 엄격히 구현한 대단(對端)이 새 메시지를 거부하거나 오해한다면, 그 변경은 상호운용을 깨뜨리는 변경이다. 이러한 변경에는 다음이 포함되나 이에 국한되지 않는다:

권위 있는 schema 필드의 의미 변경;
메시지 또는 오류 코드 제거;
오류 코드 재정의;
상태 머신의 흡수 상태(absorbing state) 변경.

WHEN 상호운용을 깨뜨리는 변경이 발생하면, MAJOR는 1 증가해야 하며 MINOR는 0으로 재설정되어야 한다.

서로 다른 MAJOR 간에는 상호운용이 보장되지 않는다.

MINOR(마이너 버전)

MINOR는 하위 호환되는 추가에 사용하며, 다음이 포함되나 이에 국한되지 않는다: 선택 필드 추가, 메시지 추가, 오류 코드 추가, 파라미터 추가, 속성 추가. 판정 기준: MAJOR.0 구버전을 엄격히 구현한 대단이 새 메시지를 거부하지도 오해하지도 않는다.

WHEN 하위 호환되는 추가가 발생하면, MINOR는 1 증가해야 하며 MAJOR는 변경되지 않은 채로 유지되어야 한다. 동일한 MAJOR 내에서 더 높은 MINOR는 MAJOR.0까지 하위 호환되어야 한다.

변경 판정 규칙(순서 있는, 결정 가능한)

임의의 변경에 대해, 그 배치는 다음 순서로 판정되어야 하며 유일한 등급을 산출한다:

MAJOR.0 구버전을 엄격히 구현한 대단이 새 메시지를 거부하거나 오해한다면 → MAJOR로 판정;
그렇지 않고 그 변경이 와이어 포맷에서 가시적인 내용(헤더/메시지/오류 코드/파라미터 등 회선상 가시 구조)을 추가한다면 → MINOR로 판정;
그렇지 않다면(텍스트만 변경, 와이어 포맷 변화 없음) → 프로토콜 버전을 변경하지 않고 편집 판차를 사용한다(§1.7.4 참조).
어떤 변경이 여러 등급에 동시에 해당하면 더 높은 등급을 취해야 한다.

1.7.3 버전 협상과 호환성 규칙

본 하위 절은 규범적이다.

와이어 포맷 제약

오직 프로토콜 버전의 MAJOR.MINOR만 와이어 포맷에 진입한다(즉 프레임 헤더 protocolVersion 필드와 schema 파일명).
프로토콜 버전은 항상 와이어 포맷에 진입해야 한다. 구현은 프로토콜 버전을 와이어 포맷에서 제외하는 설정을 제공해서는 안 된다.
문서 상태와 편집 판차는 와이어 포맷에 진입해서는 안 된다. 구현은 문서 상태나 편집 판차에 근거하여 메시지 처리 동작을 변경해서는 안 된다——즉 와이어 포맷이 완전히 동일한 두 메시지는 이 두 축의 값이 다르다는 이유로 처리 결과에 차이를 생성해서는 안 된다.
IF 수신한 메시지의 와이어 포맷에 프로토콜 버전 정보가 누락된 경우(프레임 헤더에 protocolVersion이 없거나, major / minor 하위 필드가 없거나, 그 값이 음이 아닌 정수가 아닌 경우), THEN 구현은 그 메시지를 프로토콜 오류로 거부해야 하며, 기본 또는 추론된 버전으로 처리해서는 안 된다.

협상 규칙

WHEN 핸드셰이크 또는 부트스트랩(bootstrap)을 수행할 때, 양측은 각자 지원하는 프로토콜 버전 집합을 선언해야 하며, 그 집합은 비어 있어서는 안 된다.
버전 선택은 다음을 따라야 한다: 먼저 양측이 공통으로 지원하는 최고 MAJOR를 취하고, 그다음 그 MAJOR 하에서 양측이 공통으로 지원하는 최고 MINOR를 취한다.
더 높은 MINOR를 가진 측은 더 낮은 MINOR의 대단에 서비스를 제공할 수 있어야 한다: 대단이 선언한 더 낮은 버전의 의미로 그 메시지를 처리해야 하며, 대단의 MINOR가 더 낮다는 이유만으로 거부해서는 안 된다.
IF 양측에 공통으로 지원하는 MAJOR가 존재하지 않으면, THEN 구현은 직접 프로토콜 오류로 거부해야 하며, 최선 노력(best-effort) 다운그레이드를 수행해서는 안 된다.(이 오류의 구체적 바인딩은 제10장의 VERSION_INCOMPATIBLE / 7001 참조.)
WHEN MAJOR가 같고 MINOR가 더 높은 메시지를 수신하면, 구현은 자신의 최고 MINOR의 의미로 알려진 필드를 해석하고 인식하지 못하는 선택 필드를 무시해야 하며, 거부·폐기·오류 발생해서는 안 된다.

자격 증명과 암호 스위트

WHEN 버전 롤링 업그레이드를 수행할 때, 구현은 기존의, 만료되지 않은 자격 증명 또는 토큰(credentials / tokens)을 계속 유효하게 유지해야 하며, 버전 변경만을 이유로 무효화해서는 안 된다.
WHERE 프로토콜이 이미 암호 스위트(cipher-suite) 협상 메커니즘을 갖춘 경우, 버전 협상은 동일한 방식을 재사용해야 한다(각자 선언, 공통 최고를 취함).

협상 시퀀스(Hello / Hello_Ack)와 「세션 내 버전 일치, 도중 전환 금지」의 작동 메커니즘은 제10장에 있다.

1.7.4 편집 판차와 정오

본 하위 절이 기술하는 제약은 비규범적(Non-normative) 거버넌스 제약이나, 그 「업그레이드로 위장해서는 안 된다」 조항은 프로토콜 버전 번호의 정확성에 대해 구속력을 가진다.

WHEN 확정 후 순수 텍스트 정오(오타 정정, 예제 추가, 표현 명확화, 링크 수정)를 수행할 때, 프로토콜 버전 번호(MAJOR.MINOR)를 변경하지 않은 채로 유지해야 한다. 그 정오는 새로운 배포 일자 디렉터리로 담아야 하며, 기존의 배포된 디렉터리는 동결을 유지해야 하여, 옛 참조와 링크가 깨져서는 안 된다.
편집 판차는 변경 로그(존재하는 경우)에 Editorial 범주로 등록해야 한다. front matter는 edition / date 필드로 그 판차를 표기해야 한다.
편집 판차는 오직 비규범적 변경만 허용하며, 와이어 포맷 의미, 규범적 진술, 오류 코드, 상태 머신, 상호운용 동작에 손대서는 안 된다.
강한 제약: IF 어떤 수정이 와이어 포맷 의미에 손댄다면, THEN §1.7.2에 따라 MINOR 또는 MAJOR를 증가시켜야 하며, 이를 정오(편집 판차) 배포로 위장해서는 안 된다.

1.7.5 버전 번호 배치표와 구현자 유의사항

배치표

배치 지점	무엇을 두는가	규범적 제약
와이어 엔벨로프 `protocolVersion` 필드	`MAJOR.MINOR`	오직 `MAJOR.MINOR`만 두며, 다른 레벨을 포함하지 않는다
schema 파일명	`MAJOR.MINOR`를 따른다	편집 판차로 이름을 변경해서는 안 된다(참조를 안정적으로 유지)
content-type	`application/dtp`	프로토콜 패밀리를 식별한다; 그 `version=` 파라미터는 오직 게이트웨이 라우팅 편의일 뿐, 와이어 포맷 의미가 아니다
front matter `status` / `date`	문서 거버넌스 마커	와이어 포맷에 진입하지 않는다
git tag	`dtp-v<MAJOR.MINOR>-<상태>`	tag는 본문 + 테스트 벡터 + schema를 동시에 커버해야 한다

구현자 유의사항(필독)

상호운용 판단은 오직 프로토콜 버전(MAJOR.MINOR)만 보며, 문서 상태나 편집 판차에 의존해서는 안 된다.
동일한 MAJOR는 MAJOR.0까지 하위 호환되어야 한다.
정오(편집 판차)를 프로토콜 업그레이드로 취급해서는 안 된다.
schema 파일명으로 편집 판차를 인코딩하는 것에 의존해서는 안 된다.
Draft 기간 중에는 호환성 약속이 없다.

완전한 디렉터리와 상태 규약, 그리고 확정(Draft → Final) 표준 동작은 제10장 「프로토콜 진화와 거버넌스」에 있다. 거기서 언급되는 git tag 형식, 상태 열거형, 편집 판차 정의는 본 절(§1.7)을 규칙 앵커로 삼아야 한다.