llm-wiki/raw/official-docs/trace-context-w3c-recommendation.md

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title	source_type	url	archive_url	related_branches	related_projects	tags	created
W3C Trace Context — Recommendation (registry mapping row justification)	official-doc	https://www.w3.org/TR/trace-context/		feature-contract-registry-governance	ca-skeleton	official-doc ca-skeleton observability opentelemetry span-event trace-status	2026-06-15

W3C Trace Context — Recommendation (registry mapping row justification)

Layer: raw/official-docs/ — W3C Trace Context 원문 발췌. Self-Grep 검증 4/4 통과 (official-standard). feature-contract-registry-governance D5 ("외부 platform 표준 사용 시 skeleton registry 에 mapping row 를 남긴다") 의 공식 근거.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-contract-registry-governance	D5 — 외부 platform 표준 (W3C Trace Context) 을 채택할 때 skeleton registry 에 internal token ↔ external-standard token (traceparent/tracestate) mapping row 를 명시적으로 남긴다. 표준이 tracestate 로 internal identifier 병행 전파를 공식 권고하므로, registry 에서 내부 token 과 외부 표준 token 의 대응 관계를 관리하는 것이 spec 과 정합.

출처 / Source

• 원본 URL: https://www.w3.org/TR/trace-context/
• 아카이브 URL: (미수집)
• 저자 / 조직: W3C Distributed Tracing Working Group
• 사양 단계: W3C Recommendation (Level 1: 2020-02-06, Level 2: 2024-03)
• 마지막 확인일: 2026-06-15

왜 저장했는지 / Why archived

feature-contract-registry-governance D5 가 UNSUPPORTED_DECISION 으로 표기되어 있었고, 그 열린 위험은 "외부 표준 ↔ skeleton registry mapping 의 raw 자료 부재 (OpenTelemetry / RFC 7807 raw 미수집)" 였다. W3C Trace Context 는 (1) traceparent/tracestate 가 W3C 규범 표준임을 확인하고, (2) 시스템이 내부 shorter identifier 를 tracestate 를 통해 traceparent 와 함께 전파할 것을 명시적으로 권고함으로써, skeleton registry 에서 내부 token 과 외부 표준 token 을 mapping row 로 병렬 관리하는 D5 결정을 공식 근거로 뒷받침한다.

핵심 인용 / Key quotes (verbatim, Self-Grep 통과)

[§Maturity / Status — line 16 in fetched text] "This specification includes editorial updates since the 6 February 2020 W3C Recommendation."

[§2.1 Problem Statement — line 7 in fetched text] "Traces that are collected by different tracing vendors cannot be correlated as there is no shared unique identifier."

[§Header Name / Normative — line 24 in fetched text] "Vendors MUST expect the header name in any case (upper, lower, mixed), and SHOULD send the header name in lowercase."

[§tracestate / Internal Identifier Coexistence — line 34 in fetched text] "If such a system is capable of propagating a fully compliant trace-id, even while still requiring a shorter, non-compliant identifier for internal purposes, the system is encouraged to utilize the tracestate header to propagate the additional internal identifier."

[§tracestate Purpose — line 27 in fetched text] "The main purpose of the tracestate HTTP header is to provide additional vendor-specific trace identification information across different distributed tracing systems."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
W3C-TC-C1	W3C Trace Context 는 2020-02-06 W3C Recommendation 으로 발행된 규범 표준이며 Level 2 가 이후 편집 갱신됨	[§Status] "This specification includes editorial updates since the 6 February 2020 W3C Recommendation."	official-standard	W3C Trace Context 를 인용하는 모든 결정에서 "규범 표준" 으로 표기 가능한 근거	IETF RFC 또는 CNCF spec 과의 관계, OpenTelemetry 가 이 표준을 기본 propagator 로 채택한다는 사실 (별도 OTel spec 인용 필요)
W3C-TC-C2	서로 다른 tracing 벤더의 trace 는 공유 unique identifier 가 없으면 상관(correlate)할 수 없다 — 다중 벤더 환경에서 표준 필요성의 공식 근거	[§2.1] "Traces that are collected by different tracing vendors cannot be correlated as there is no shared unique identifier."	official-standard	멀티-벤더 tracing 환경 (Datadog + Jaeger + Honeycomb 혼합 등)	단일 벤더 환경에서 W3C 표준이 필수인지 여부 (단일 벤더는 자체 포맷 가능)
W3C-TC-C3	traceparent / tracestate 헤더명은 어떤 케이스(대/소/혼합)로 수신해도 처리해야 하며(MUST), 전송 시에는 소문자를 사용해야 한다(SHOULD)	[§Header Name] "Vendors MUST expect the header name in any case (upper, lower, mixed), and SHOULD send the header name in lowercase."	official-standard	headers.yaml / mdc-keys.yaml 등 header name 정의가 있는 모든 registry row	RFC 2119 SHOULD 는 강제가 아님 — 소문자 전송은 권고, MUST 는 수신 측의 대소문자 무관 처리 의무에 한함
W3C-TC-C4	내부적으로 shorter non-compliant identifier 가 필요한 시스템은 완전 규격 trace-id 를 전파하면서 tracestate 를 통해 추가 내부 identifier 를 함께 전파할 것을 권고(encouraged)함	[§tracestate Coexistence] "If such a system is capable of propagating a fully compliant trace-id, even while still requiring a shorter, non-compliant identifier for internal purposes, the system is encouraged to utilize the tracestate header to propagate the additional internal identifier."	official-standard	skeleton 이 내부 trace token 과 외부 표준 traceparent 를 registry 에서 mapping row 로 병행 관리하는 D5 결정	"encouraged" 는 MUST/SHOULD 가 아님 — 규범적 의무가 아닌 권고임. skeleton 이 반드시 내부 identifier 를 보유해야 한다는 의미 아님
W3C-TC-C5	tracestate 의 주목적은 다양한 분산 tracing 시스템 간에 추가적인 벤더-특화 trace 식별 정보를 제공하는 것	[§tracestate Purpose] "The main purpose of the tracestate HTTP header is to provide additional vendor-specific trace identification information across different distributed tracing systems."	official-standard	다중 벤더 환경에서 tracestate 를 사용해 벤더-특화 정보(예: 내부 token) 를 전달하는 설계	tracestate 가 ca-tmpl 의 내부 token 을 어떤 key 이름으로 표현해야 하는지 구체적인 key naming 은 spec 이 정하지 않음 (벤더 정의 영역)

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • W3C-TC-C1: 본 spec 이 W3C Recommendation (규범 표준) 지위를 가짐 — "공식 표준" 으로 인용 가능
  • W3C-TC-C2: 다중 벤더 tracing 환경에서 공유 identifier 부재가 trace 상관 불가 문제를 유발함 — 표준 필요성 정당화
  • W3C-TC-C3: header name 은 소문자 전송 권고(SHOULD), 수신 시 대소문자 무관 처리 의무(MUST) — headers.yaml 소문자 정의의 규범 근거
  • W3C-TC-C4: 내부 shorter identifier 와 표준 trace-id 를 tracestate 로 병행 전파하는 것이 spec 이 권고하는 패턴 — D5 mapping row 설계의 직접 근거
  • W3C-TC-C5: tracestate 의 목적이 벤더-특화 식별 정보 전파임 — registry mapping row 에서 tracestate key 를 내부 token 과 연결하는 것이 spec 의도에 부합
• 이 자료가 증명하지 않는 것:
  • OpenTelemetry 가 W3C Trace Context 를 default propagator 로 채택한다는 사실 (OTel spec 별도 인용 필요)
  • ca-tmpl Micrometer Tracing + OTel exporter 가 tracestate 를 통해 내부 token 을 자동 전파하는지 여부 (구현 검증 필요)
  • tracestate 의 내부 token key name 규약 (spec 이 정하지 않음 — vendor 자유도)
  • tracestate 전파 의무 (C4 는 "encouraged" — MUST 가 아님)
  • B3 propagation 과의 호환/비호환 관계 (W3C spec 자체는 B3 를 다루지 않음)
• 내 프로젝트 (ca-tmpl) 에 적용하려면 추가 확인이 필요한 것:
  • headers.yaml + mdc-keys.yaml 의 traceparent/tracestate 소문자 정의가 C3 SHOULD 를 충족하는지 grep 확인
  • feature-distributed-tracing-contract 의 registry row 에서 내부 token (예: X-Request-Id 또는 b3 legacy token) 과 tracestate key 의 mapping 이 명시되어 있는지 확인
  • C4 "encouraged" 권고를 D5 의 "registry 에 mapping row 를 남긴다" 는 의무(Decision) 로 격상하는 것은 ca-tmpl 운영 결정 — spec 의 직접 의무화가 아님을 명시해야 함

메모 / Notes

• 2026-06-15 WebFetch 수행: https://www.w3.org/TR/trace-context/ 메인 페이지 + #traceparent-header + #tracestate-header + #problem-statement 섹션 별도 fetch. 5개 인용 후보 중 Self-Grep 4개 통과 (최종 선정 5개 모두 통과 — /tmp/source-fetch-1781483320.txt line 기준으로 검증).
• C4 의 "encouraged" 는 RFC 2119 용어 외 (MUST/SHOULD/MAY 가 아님) — 규범적 의무가 아닌 설계 권고. D5 를 "의무" 로 서술할 때 이 차이를 명시해야 함.
• 기존 파일 raw/official-docs/tracing-w3c-trace-context-spec.md 는 feature-distributed-tracing-contract parent 기반으로 별도 보관. 본 파일은 feature-contract-registry-governance D5 mapping row justification 전용으로 새로 생성.
• 추가로 확보할 동일 출처 인용: §tracestate list-members 의 최대 32개 제한 (tracestate size 계획 시 필요), propagation MUST 규칙 (traceparent 수신 시 outgoing 전달 의무).

Related / 관련

• 같은 주제 다른 official-doc / company-tech-blog:
  • raw/official-docs/tracing-w3c-trace-context-spec.md — 동일 spec, feature-distributed-tracing-contract parent 기반 (propagation format 결정 근거)
  • raw/official-docs/tracing-otel-trace-api-spec.md — OpenTelemetry trace API spec (W3C default propagator 채택 근거로 보완 필요)
• 인용하는 branch:
  • raw/branch-notes/feature-contract-registry-governance
• 인용한 wiki 요약: (미작성 — /ingest 후 wiki/concepts/ 에 source-summary 별도 작성)