스펙들 3
탐색 1.0.1 문서
버전
문서 변경 이력
섹션 7
현재 페이지 11
1.0.1 ko public

스펙

RAWP-CRS

Compliance rendering specification for RAWP consumers.

변경 이력 전체 Markdown 목차 Markdown

3. 유저 메시지 (User Message)

유저 메시지의 설계 목표는 사용자가 1:1 채팅을 하고 있다는 자연스러운 경험을 제공하는 것이다. 시각적 형태는 친숙한 메신저 앱의 발신 메시지 관례를 따른다.

3.1. 버블 스타일 및 레이아웃

우측 정렬 채팅 버블: 유저 메시지는 대화 영역의 우측에 배경색이 있는 둥근 모서리(border-radius) 버블로 렌더링해야 한다 (MUST). 버블의 최대 너비는 대화 영역 전체 폭의 70~80%로 제한하여 좌측에 여백을 확보하고, 에이전트 메시지와의 시각적 대칭을 유지한다 (SHOULD).

텍스트 메시지: control.prompt.request에서 input_type: "text"인 메시지는 입력된 텍스트를 버블 내에 마크다운 서식을 적용하여 표시한다.

유저 메시지 서식 인식: 유저 메시지 버블 내에서 다음의 텍스트 마크다운 서식을 인식하고 렌더링해야 한다 (MUST):

서식 구문 렌더링
볼드 **text** 또는 __text__ font-weight: bold 적용
이텔릭 *text* 또는 _text_ font-style: italic 적용
볼드+이텔릭 ***text*** 볼드와 이텔릭 동시 적용
취소선 ~~text~~ text-decoration: line-through 적용
인라인 코드 `code` 모노스페이스 폰트, 배경색 구분
줄바꿈 Enter 키 (\n) 또는 Shift+Enter <br> 줄바꿈 표시
링크 [text](url) 클릭 가능한 하이퍼링크
자동 링크 URL 패턴 자동 감지 클릭 가능한 링크로 변환

다음 서식은 유저 메시지에서 렌더링하지 않는다 (MUST NOT): 헤더(#), 펜스 코드 블록(```), 테이블(| |), 이미지(![]()), 목록(-, 1.), 인용구(>), 수평선(---), 수식($). 유저 메시지는 대화형 텍스트이므로 블록 레벨 구조는 적용하지 않고, 인라인 텍스트 서식만 인식한다.

입력창에서의 서식 입력: 입력창은 사용자가 마크다운 구문을 직접 타이핑하는 플레인 텍스트 모드를 기본으로 한다 (MUST). 서식이 적용된 리치 텍스트 미리보기는 입력 중에 표시하지 않는다 (MUST NOT). 마크다운 구문은 전송 후 대화 이력에 표시될 때 렌더링된다.

파일 참조 토큰 렌더링: 전송 완료된 메시지가 대화 이력에 표시될 때, prompt_text 내 파일 참조 토큰이 포함되어 있는 경우 §3.4.5의 토큰 시각 사양(배경색, 둥근 모서리, 아이콘)과 동일한 스타일로 인라인 렌더링해야 한다 (MUST). 대화 이력 내 토큰은 읽기 전용이며, 클릭 시 해당 파일의 경로를 클립보드에 복사하거나 파일 뷰어를 여는 동작을 지원할 수 있다 (MAY).

토큰 검증 규칙: 대화 이력에서 유저 메시지를 렌더링할 때, prompt_text 내 토큰 패턴이 file_references에 유효하게 매핑되는 경우에만 시각적 토큰으로 렌더링한다 (MUST). 매핑되지 않는 토큰 패턴은 RAWP-DPS §16.2.2에 따라 언이스케이프 후 리터럴 텍스트로 표시하여, 위조된 토큰이 시각적으로 정당한 파일 참조처럼 보이는 것을 방지한다 (MUST).

§3.3(슬래시 명령어 실행 버블)의 "중첩 컨테이너 금지" 원칙을 동일하게 따른다. 토큰의 배경색이 버블 배경색과 충분히 구분되어야 하며 (MUST), 버블 내에 별도의 컨테이너(카드, 박스 등)를 추가하지 않는다.

3.2. 슬래시 명령어 입력 (Slash Command Input)

사용자가 입력창에 / 문자를 타이핑하면, 클라이언트는 agent.commands.publish(RAWP-DPS §12.1.1)를 통해 수신한 명령어 목록을 기반으로 자동 완성 UI를 즉시 표시해야 한다 (MUST).

트리거 조건: 입력창에서 커서가 행 시작 위치이거나 공백 직후에 / 문자가 입력되면, 자동 완성 팝업을 활성화해야 한다 (MUST). 문장 중간의 슬래시(예: https://..., path/to/file)에서는 활성화해서는 안 된다 (MUST NOT).

팝업 위치 및 반응 속도: 자동 완성 팝업은 입력창 바로 위(또는 아래, 뷰포트 공간에 따라 동적 결정)에 오버레이로 표시해야 한다 (MUST). 기존 대화 이력이나 응답 영역을 가려서는 안 되며 (SHOULD NOT), 입력 커서와의 시각적 연결성을 유지해야 한다. / 입력 후 팝업 표시까지의 지연은 100ms를 초과해서는 안 된다 (SHOULD NOT). agent.commands.publish로 수신한 명령어 목록은 세션 시작 시 로컬에 캐싱하여 네트워크 지연 없이 즉시 표시할 수 있어야 한다 (MUST).

목록 구성: 각 명령어 항목은 다음 요소를 포함하여 표시해야 한다 (MUST):

  • 명령어 이름: /{name} 형식으로 좌측에 고정 표시. 모노스페이스 폰트 적용 (SHOULD).
  • 설명(description): 명령어 이름 우측 또는 하단에 간략한 설명 텍스트를 표시.
  • 카테고리 표지: category 필드가 존재하면, 색상 뱃지 또는 아이콘으로 시각적 그룹핑을 제공할 수 있다 (MAY). 예: session 카테고리는 🔄, display는 👁, config는 ⚙ 등.

항목 간 시각적 분리 (Item Separation): 명령어 목록의 각 항목은 인접 항목과 명확히 구분되어야 한다 (MUST). 다음 방법 중 하나 이상을 적용한다:

  • 충분한 내부 패딩: 각 항목에 상하 패딩(예: 8~12px)을 부여하여 텍스트가 경계에 밀착되지 않도록 한다 (MUST). 항목 간 여백 없이 패딩만으로 구분이 충분하면 구분선은 생략할 수 있다.
  • 구분선 또는 배경 교차: 항목 사이에 얇은 구분선(1px, 저대비 색상)을 삽입하거나, 짝수/홀수 항목에 미세하게 다른 배경색(zebra striping)을 적용할 수 있다 (MAY).
  • 명령어명-설명 레이아웃: 명령어 이름과 설명 텍스트는 시각적 위계가 명확해야 한다 (MUST). 명령어명은 볼드 또는 기본 텍스트 색상, 설명은 연한 색상(muted color)과 작은 폰트 크기로 차등을 둔다.

실시간 필터링: 사용자가 / 이후 추가 문자를 타이핑하면(예: /com), 입력된 접두사와 일치하는 명령어만 팝업에 필터링하여 표시해야 한다 (MUST). 필터링은 명령어 이름(name)에 대한 접두사 매칭을 기본으로 하되, 퍼지 매칭(fuzzy match)을 추가 지원할 수 있다 (MAY). 필터링 결과가 갱신될 때, 포커스는 목록의 첫 번째 항목으로 리셋되어야 한다 (SHOULD). 입력된 접두사에 매칭되는 명령어가 없으면, 팝업에 "일치하는 명령어가 없습니다" 등의 안내 메시지를 표시해야 한다 (SHOULD). 팝업을 즉시 닫아서는 안 된다 (MUST NOT) — 사용자가 타이핑을 수정할 기회를 보장해야 한다.

정렬 순서: 명령어 목록은 다음 우선순위로 정렬할 것을 권장한다 (SHOULD): 사용 빈도 높은 순 → category별 그룹핑 → 알파벳순.

포커스 하이라이트 (Focus Highlight): 키보드 또는 마우스로 현재 선택 대상이 되는 항목은, 다른 항목과 즉각적으로 구별되는 하이라이트를 적용해야 한다 (MUST). 하이라이트는 해당 항목의 전체 행 영역(좌측 끝~우측 끝)에 배경색을 적용하는 방식이어야 하며, 텍스트 일부만 강조하거나 밑줄만 추가하는 방식은 불충분하다. 하이라이트 배경색은 비선택 항목의 배경과 충분한 명도 차이를 가져야 한다 (MUST). 동시에 두 개 이상의 항목이 하이라이트되어서는 안 된다 (MUST NOT). 키보드 포커스와 마우스 호버가 서로 다른 항목을 가리킬 경우, 마우스 호버가 우선한다 (SHOULD).

키보드 내비게이션: 팝업이 활성화된 상태에서 다음 키보드 조작을 지원해야 한다 (MUST):

키 동작
↑ / ↓ 목록 항목 간 포커스 이동. 목록 끝에서 순환 (SHOULD).
Enter 또는 Tab 포커스된 항목 선택 및 입력창에 반영
Esc 팝업 닫기, 입력 텍스트는 유지
계속 타이핑 실시간 필터링 갱신. 포커스는 필터링된 목록의 첫 항목으로 리셋

팝업 내 목록이 스크롤 가능한 길이일 때, 키보드 포커스가 현재 보이는 영역 밖으로 이동하면 포커스된 항목이 뷰포트 내에 보이도록 팝업 내부를 자동 스크롤해야 한다 (MUST). 마우스 클릭 또는 터치 탭으로도 선택할 수 있어야 하며 (MUST), 마우스 호버 시 해당 항목에 포커스 하이라이트와 동일한 배경색을 즉시 적용해야 한다 (MUST).

선택 후 동작: 명령어가 선택되면, 입력창의 텍스트를 /{선택된_name} (후행 공백 포함)으로 교체하고 팝업을 닫아야 한다 (MUST). parameters 배열에 required: true인 항목이 있으면, 선택 후 입력창에 해당 파라미터의 힌트를 회색 플레이스홀더로 표시하여 사용자가 추가 입력이 필요함을 인지하도록 해야 한다 (SHOULD).

명령어 목록 갱신: agent.commands.publish 이벤트가 세션 중 재수신되면, 클라이언트는 로컬 캐시를 즉시 갱신해야 한다 (MUST). 팝업이 열려 있는 상태에서 갱신이 발생하면, 현재 필터 조건을 유지한 채 목록을 교체해야 한다 (SHOULD). 갱신 과정에서 사용자의 포커스 위치나 입력 상태가 초기화되어서는 안 된다 (MUST NOT).

3.3. 슬래시 명령어 실행 버블 렌더링 (Command Bubble)

사용자가 슬래시 명령어를 실행하면, 대화 이력에 표시되는 채팅 버블은 일반 텍스트 메시지와 명확히 구별되는 전용 렌더링을 적용해야 한다 (MUST).

슬래시 접두사 제거: 채팅 버블에 명령어를 표시할 때 선행 / 문자는 제거해야 한다 (MUST). 예: 사용자가 /compact focus on auth module을 입력했다면, 버블에는 compact focus on auth module로 표시한다.

중첩 컨테이너 금지 (No Nested Containers): 명령어 버블은 버블 자체가 뱃지(badge) 역할을 겸해야 하며, 버블 내부에 별도의 뱃지, 칩(chip), 또는 박스 요소를 중첩해서는 안 된다 (MUST NOT).

명령어명 강조: 버블 내에서 명령어명(첫 번째 토큰)은 중첩 컨테이너 없이 인라인 텍스트 스타일로 구분해야 한다 (MUST). 명령어명은 볼드(font-weight: bold) 와 일반 텍스트 대비 약간 다른 색상을 적용하여 시각적으로 구분한다. 파라미터가 존재하면 일반 두께의 텍스트로 이어서 표시한다. 예: compact focus on auth module.

버블 스타일 차별화: 명령어 버블은 그 자체로 일반 메시지와 즉시 구분되어야 한다 (MUST). 다음 조합을 적용한다:

  • 인라인 크기: 내용 길이에 맞춰 최소 폭으로 렌더링 (SHOULD). 일반 메시지처럼 넓은 영역을 차지하지 않고, 컴팩트한 인라인 요소로 표시한다.
  • 배경색 차별화: 일반 메시지 버블과 명확히 다른 배경색을 적용한다.
  • 모노스페이스 폰트: 버블 전체에 모노스페이스 폰트를 적용 (SHOULD).
  • 아이콘 접두: 명령어명 좌측에 소형 아이콘(예: ⚡, ▶)을 표시할 수 있다 (MAY).

실행 결과 연결: 명령어 버블 직후에 에이전트의 응답이 이어지는 경우, 명령어 버블과 결과 영역 사이의 시각적 연결성을 표현하여 인과 관계를 명확히 해야 한다 (SHOULD).

프로토콜 연계: control.prompt.request에서 input_type: "slash_command"(RAWP-DPS §6.1.1)로 설정된 프레임은 본 섹션의 Command Bubble 스타일을 적용해야 한다 (MUST). input_type: "text" 또는 기타 값인 경우에는 §3.1의 일반 메시지 버블 스타일을 유지한다.

3.4. 파일 참조 입력 (File Reference Input)

사용자가 @ 문자를 입력하여 로컬 파일을 인라인으로 참조하는 기능의 렌더링 및 UX 규격이다. 슬래시 명령어(§3.2)와 유사한 자동 완성 팝업 UI 패턴을 따르되, 파일 퍼지 검색의 특성에 맞게 확장한다.

3.4.1. 트리거 조건

활성화 조건: 입력창에서 커서가 행 시작 위치이거나 공백 직후에 @ 문자가 입력되면, 파일 검색 팝업을 활성화해야 한다 (MUST).

비활성 조건: 다음의 경우에는 팝업을 활성화해서는 안 된다 (MUST NOT):

  • @ 직전 문자가 영숫자(a-z, A-Z, 0-9)이거나 .인 경우. 이는 이메일 주소 패턴(user@domain), URL 내 @, 또는 단어 중간의 @를 필터링한다.
  • 슬래시 명령어 팝업(§3.2)이 이미 활성 상태인 경우. §3.4.7 참조.

3.4.2. 팝업 UI 구성

위치 및 반응 속도: §3.2(슬래시 명령어)의 팝업 위치 규칙과 동일하게 입력창 바로 위에 오버레이로 표시한다 (MUST). 기존 대화 이력이나 응답 영역을 가려서는 안 되며 (SHOULD NOT), 입력 커서와의 시각적 연결성을 유지해야 한다. @ 입력 후 팝업 표시까지의 지연은 100ms를 초과해서는 안 된다 (SHOULD NOT).

초기 상태: @ 입력 직후(쿼리 문자열이 비어 있는 시점), 팝업은 다음 중 하나를 표시해야 한다 (MUST):

  • 최근 수정된 파일 목록 (클라이언트가 DPS control.file.search의 빈 쿼리 응답으로 제공)
  • "파일명을 입력하세요" 안내 메시지 + 로딩 인디케이터

후보 항목 구성: 각 파일 후보 항목은 다음 요소를 포함하여 표시해야 한다 (MUST):

  • 파일 아이콘 (MAY): 확장자별 아이콘 또는 이모지를 좌측에 표시한다. 아이콘 매핑 예시:

    확장자 그룹 아이콘/이모지 예시
    .ts, .tsx, .js, .jsx 📜 또는 JS/TS 아이콘
    .py 🐍 또는 Python 아이콘
    .json, .yaml, .toml ⚙ 또는 설정 아이콘
    .md, .txt 📄
    .css, .scss 🎨
    기타 / 알 수 없음 📁 (기본 파일 아이콘)

    아이콘 매핑은 클라이언트 구현에 위임하며, 본 규격은 강제하지 않는다 (MAY). 단, 아이콘을 제공하는 경우 모든 후보에 일관되게 적용해야 한다 (MUST).

  • 파일명: 볼드 또는 기본 텍스트 색상으로 좌측에 표시. DPS session.file.candidates의 match_ranges가 제공된 경우, 매칭된 문자 범위를 강조 배경색 또는 볼드로 하이라이팅해야 한다 (MUST).

  • 디렉토리 경로: 파일명 우측 또는 하단에 연한 색상(muted color)으로 표시. 긴 경로는 선행 부분을 말줄임(…/deep/path/to/)으로 축약할 수 있다 (MAY).

항목 간 시각적 분리: §3.2의 항목 간 시각적 분리 규칙과 동일하게, 충분한 내부 패딩(8~12px)과 선택적 구분선을 적용한다 (MUST).

3.4.3. 퍼지 검색 동작

실시간 검색 요청: 사용자가 @ 이후 추가 문자를 타이핑하면, 클라이언트는 DPS control.file.search 이벤트 발송을 위해 입력을 마스터에 전달해야 한다 (MUST). 키스트로크마다 즉시 전송하지 않고, 150~300ms 디바운싱을 적용하여 네트워크 부하를 제어해야 한다 (SHOULD).

로딩 상태: 검색 요청 발송 후 session.file.candidates 수신 전까지, 팝업 하단에 로딩 인디케이터(스피너 또는 프로그레스 바)를 표시해야 한다 (MUST). 이전 결과가 존재하면 이전 결과를 유지한 채 로딩 인디케이터를 병행 표시하여, 화면이 빈 상태로 깜빡이는 것을 방지한다 (SHOULD).

결과 순서 보장: 클라이언트는 session.file.candidates의 query_id를 확인하여, 현재 활성 쿼리의 결과만 팝업에 반영해야 한다 (MUST). query_id가 현재 활성 쿼리와 불일치하는 응답(이전 쿼리의 지연 도착)은 무시한다 (MUST).

빈 결과 처리: 매칭 결과가 없으면 "일치하는 파일이 없습니다" 안내 메시지를 표시해야 한다 (SHOULD). 팝업을 즉시 닫아서는 안 된다 (MUST NOT) — 사용자가 타이핑을 수정할 기회를 보장해야 한다.

3.4.4. 키보드 및 포인터 내비게이션

§3.2의 키보드 내비게이션 규칙을 동일하게 적용한다 (MUST):

키 동작
↑ / ↓ 목록 항목 간 포커스 이동. 목록 끝에서 순환 (SHOULD).
Enter 또는 Tab 포커스된 항목 선택 및 입력창에 반영
Esc 팝업 닫기, @ 포함 입력 텍스트는 유지
계속 타이핑 퍼지 검색 갱신. 포커스는 목록의 첫 항목으로 리셋 (SHOULD)

포커스 하이라이트, 자동 스크롤, 마우스/터치 조작 규칙도 §3.2와 동일하다.

추가 규칙: /(슬래시) 키 입력은 디렉토리 구분자로서 검색 쿼리에 포함되어야 하며, 슬래시 명령어 팝업을 트리거해서는 안 된다 (MUST NOT). 즉, @ 팝업이 활성 상태인 동안 / 입력은 파일 경로 검색의 일부로 처리한다.

3.4.5. 선택 후 동작: 파일 참조 토큰 렌더링

사용자가 파일을 선택하면, 입력창에서 @{타이핑한_텍스트}를 인라인 파일 참조 토큰으로 교체해야 한다 (MUST). 이 토큰은 입력창 내에서 일반 텍스트와 시각적으로 명확히 구분되는 독립적 시각 요소로 렌더링한다.

토큰 시각 사양:

  • 배경색: 본문 입력 영역의 배경과 구분되는 연한 강조색(예: 연한 파란색 #E3F2FD, 또는 테마의 primary 색상의 10~15% 불투명도)을 적용한다 (MUST).
  • 둥근 모서리: border-radius: 3~4px를 적용하여 토큰의 경계를 시각적으로 명확히 한다 (MUST).
  • 내부 패딩: 좌우 46px, 상하 12px의 미세한 패딩을 부여한다 (SHOULD).
  • 텍스트 내용: 파일명만 표시하거나, 짧은 경우 상대 경로 전체를 표시한다. 경로가 긴 경우 …/ 접두로 축약할 수 있다 (MAY).
  • 파일 아이콘 (MAY): 토큰 좌측에 확장자별 소형 아이콘 또는 이모지를 표시한다. §3.4.2의 아이콘 매핑을 따른다. 아이콘은 텍스트와 동일한 줄높이 내에서 수직 중앙 정렬한다.
  • 폰트: 모노스페이스 폰트를 적용하여 파일 경로임을 시각적으로 암시한다 (SHOULD). 폰트 크기는 입력창의 본문 텍스트와 동일하게 유지한다.

토큰 동작:

  • 토큰은 커서 이동 시 원자 단위(atomic unit) 로 취급한다 (MUST). 좌/우 화살표로 커서가 토큰에 도달하면 토큰 전체를 건너뛴다. 토큰 내부에 커서가 진입하지 않는다.
  • 토큰을 포함한 텍스트의 복사/붙여넣기 시, 토큰은 @파일명 형태의 플레인 텍스트로 변환된다 (SHOULD).

토큰 삭제 (Fluid Deletion):

토큰 삭제는 커서 위치에 관계없이 물 흐르듯 자연스러운 시각적 연속성을 유지해야 한다 (MUST). 삭제 과정에서 대화 흐름이 끊기거나 레이아웃이 점프해서는 안 된다 (MUST NOT).

  • Backspace (토큰 직후에서): 첫 번째 Backspace로 토큰 전체를 선택(하이라이트) 상태로 전환한다 (MUST). 하이라이트된 토큰은 배경색 변경(예: 기존 연한 파란색 → 연한 빨간색 #FFEBEE 또는 테마의 danger 색상 10~15% 불투명도)으로 삭제 예정 상태임을 표시한다. 두 번째 Backspace로 토큰을 삭제한다.
  • Delete (토큰 직전에서): Backspace와 동일한 2단계 동작을 Delete 키에도 적용해야 한다 (MUST).
  • 삭제 애니메이션: 토큰이 삭제될 때 너비를 0으로 축소하는 트랜지션(100~150ms)을 적용하여 후속 텍스트가 부드럽게 당겨지도록 해야 한다 (MUST). 즉시 제거하여 텍스트가 갑자기 이동하는 것은 허용하지 않는다 (MUST NOT).
  • 범위 선택 삭제: 사용자가 마우스 드래그 또는 Shift+화살표로 토큰을 포함하는 텍스트 범위를 선택한 후 삭제하면, 선택 범위 내의 토큰은 2단계 확인 없이 즉시 삭제한다 (MUST). 이 경우에도 삭제 애니메이션은 적용한다 (SHOULD).
  • Undo 지원: 토큰 삭제 후 Ctrl+Z(macOS: Cmd+Z)로 토큰을 복원할 수 있어야 한다 (MUST). 복원 시 토큰의 메타데이터(ref_id, 파일 경로 등)도 함께 복원된다.

복수 참조: 단일 메시지 내에 여러 개의 파일 참조 토큰이 존재할 수 있다 (MUST 지원). 각 토큰은 독립된 ref_id를 가지며, 동일 파일을 중복 참조하더라도 별개의 토큰으로 취급한다.

3.4.6. 메시지 전송 시 변환 및 이스케이프

사용자가 메시지를 전송하면, 클라이언트는 입력창의 콘텐츠를 다음 두 영역으로 분리하여 처리해야 한다 (MUST):

  • 토큰 영역: UI 파일 선택을 통해 삽입된 인라인 토큰. DPS §16.2.1의 토큰 포맷(<@file:ref_id|display_path>)으로 변환한다. 이스케이프를 적용하지 않는다.
  • 텍스트 영역: 사용자가 키보드로 직접 입력한 모든 나머지 텍스트. DPS §16.2.2의 이스케이프 규칙을 적용하여 \ → \\, <@ → \<@ 변환을 수행한다.

이 분리는 입력창의 내부 데이터 모델에서 토큰 노드와 텍스트 노드를 구분하여 관리함으로써 구현한다. 입력창이 단순 텍스트 필드(<input>, <textarea>)인 경우에도, 토큰 삽입 시점에 내부적으로 토큰 위치와 메타데이터를 별도 추적해야 한다 (MUST).

각 토큰에 대응하는 file_references 배열을 구성하여 DPS control.prompt.request의 payload에 포함한다 (MUST).

3.4.7. 슬래시 명령어와의 상호 배타

@ 팝업이 활성 상태인 동안 / 입력은 파일 경로의 일부로 처리하며, 슬래시 명령어 팝업을 트리거하지 않는다 (MUST). 역으로, / 팝업이 활성 상태인 동안 @ 입력은 명령어 인자의 일부로 처리한다 (SHOULD). 동시에 두 팝업이 활성화되어서는 안 된다 (MUST NOT).

Part 1 끝. §4 에이전트 메시지, §5 시스템 메시지, §6 비스트리밍 환경 적응 및 부록은 Part 2를 참조하십시오.

RAWP-CRS 1.0: Client Rendering Specification — Part 2 (§4–§6, 부록)

본 파일은 RAWP-CRS 1.0의 §4–§6 및 부록을 포함합니다. §1–§3(파일 참조 입력 §3.4 포함)은 Part 1을 참조하십시오.

항목 값
상태 Stable
버전 1.0.1
상위 규격 RAWP 1.0.2
데이터 평면 규격 RAWP-DPS 1.0.1

참조