요약

  • W3C의 네임스페이스 페이지는w3.org/2026/08/xmldsig-more#가 XML Security에 할당되었고 마지막으로 2026년 8월 19일에 수정되었다고 밝히지만, 번호가 매겨진 개정판이 아니라 최신 초안 보기로 연결된다.
  • RFC 9231bis 개정판-08은 여전히w3.org/tbd#를 사용했다. 8월 21일에 게시된-09가 처음으로 새 네임스페이스로 대체했으며 다른 자료도 함께 추가했다. 공개 기록은 할당이 어떤 바이트를 커버했는지 말해 주지 않는다.
  • W3C 자체 지침은 네임스페이스 변경 정책이 이름을 누가, 어떻게 정의하거나 제거할 수 있는지 명시해야 한다고 말한다. 새 네임스페이스 문서는 그런 규칙을 담고 있지 않으며, 침묵은 가변성도 불변성도 증명하지 않는다.
  • 네임스페이스 변경 헌장은 할당을 개정판과 해시에 묶고, 동결 전 편집 권한과 호환성 처리를 명시하고, 동결 시점이 되는 행위를 지명하며, W3C·IETF·IANA 상태를 분리 유지해야 한다.
  • 이는 무효한 할당, 알고리즘 승인, IETF 채택, 레지스트리 지연 또는 협력 실패에 대한 주장이 아니다. 조기 할당과 초안 반복은 정당하며, 단지 그 권한 연쇄가 아직 하나로 결합된 기록으로 공개되지 않았을 뿐이다.

네임스페이스는 그것을 사용하는 개정판보다 먼저 도착했다

W3C 네임스페이스 문서는 몇 줄에 불과하다. 이 문서는 해당 URI가 “XML Security에 할당되었다”고 말하고, 어떤 사양에 해당한다고 기술하며, Datatracker의draft-eastlake-rfc9231bis-xmlsec-uris최신 보기로 연결하고, “2026-08-19에 Simone Onofri가 마지막으로 수정”이라고 기록한다.

그 간결함 자체가 결함은 아니다. 네임스페이스 문서는 종종 내구성 있는 이정표 역할을 한다. 안정된 URI는 편집자가 임시 식별자를 새로 만드는 일을 멈추게 하고, 사양 간 검토를 가능하게 하며, 독립 구현체가 충돌하는 이름을 선택할 가능성을 줄인다. 논의 중의 할당은 조기 승인이 아니라 활성화 행위일 수 있다.

그러나 이 이정표는 움직이는 목적지를 가리킨다. 번호가 매겨진 초안, 해시, 할당 요청, 접두어를 승인한 사람이나 기구, 그리고 그 로컬 이름이 변경될 수 있는 조건을 식별하지 않는다. 다음 달에 도착한 독자는 최신 초안을 볼 수 있다. 그러나 W3C가 권한을 부여할 때 어떤 초안 상태를 보았는지는 볼 수 없다.

이 구분은 이틀 만에 구체화되었다.

초안이 바뀌면서 공개 조율도 형태가 바뀌었다

W3C Strategy 이슈는 2024년 11월 17일, XML Signature와 XML Encryption의 포스트 양자 암호학에 관한 워크숍 제안으로 시작되었다. 그것은 광범위한 문제, 여러 사용 사례, 그리고 RFC 9231의 가능한 업데이트를 기술했다. 이 이슈는 공개 조율의 유용한 증거다. 그러나 권고안도, 헌장도, 이행 결정도, 투표도 아니다.

2024년 11월 21일개인 초안의 저자가 RFC 9231bis 작업에 알고리즘을 추가하겠다고 제안했다.2025년 6월 14일공개 댓글은 HSS/LMS, ML-DSA, SLH-DSA, ML-KEM을 나열하며, 어쩌면 GitHub 이슈가 원래 워크숍을 위해 상상된 작업을 수행할 수 있다고 제안했다. 이것들은 유용한 일을 하는 사람들 사이의 보이는 악수다. 저자의 제안이나 이슈 댓글 어느 것도 W3C나 IETF의 기관적 승인을 만들어 내지는 않는다.

속도는 2026년 8월에 빨라졌다.8월 17일 업데이트는 개정판-08이 추적 중인 네 가지 알고리즘 계열을 커버했으며-09가 FrodoKEM과 SignatureContext 자료를 담아 준비 중이고, 또 다른 질문이 열려 있다고 말했다. 네임스페이스 페이지에는 8월 19일의 수정 날짜가 있다. 이어서 초안 저자가8월 21일-09를 발표했다.8월 26일이 이슈의 공개 목적이 재정의되었다. 더 이상 워크숍 개최가 아니라 XML Signature와 XML Encryption 업데이트의 필요성을 추적하는 것이 되었다.

이것이 건강한 작업 조율이 흔히 보이는 모습이다. 의도된 장소가 바뀌고, 초안이 제안을 흡수하고, 열린 질문이 남고, 공개 이슈가 용도가 변경된다. 그렇기 때문에 네임스페이스 권한에는 버전 수취증이 필요하다. 살아 있는 작업 흐름에 할당된 URI는 그것을 처음 정당화한 특정 이슈, 기여자, 문서 상태보다 오래 남을 수 있다.

여기 어떤 공개 출처도 W3C가 검토한 정확한 초안 바이트를 확립하지 않는다. 내부 기록이 존재하지 않는다고 단언하는 것 역시 똑같이 정당하지 않다. 증거는 더 좁은 관찰을 지지한다. 네임스페이스 페이지는 그 연결을 노출하지 않는다.

두 개정판이 결여된 연결을 측정 가능하게 만든다

현재 Datatracker 기록은 증거 기준 시점에 개정판-09를 보여 주었다. 또한 이 작업을 활성 개인 인터넷 드래프트로 표시했으며, IESG 상태는I-D Exists, 정의된 RFC 스트림은 없고 책임 영역 이사(Area Director)도 없었다. 이 기록은 누구나 인터넷 드래프트를 제출할 수 있고 저장소에 게시되는 것이 문서에 공식적인 IETF 지위나 승인을 주지 않는다고 경고한다.

문서 자체에는 또 다른, 양립 가능한 상태 계층이 있다. 저자를 Independent로 식별하고, “Obsoletes: 9231 (if approved)”라고 쓰며, 의도된 지위로 “Standards Track”을, 만기일로 2027년 2월 22일을 제시한다. 헤더는 저자가 무엇을 추구하는지, 조건부로 무엇이 일어날지를 말한다. Datatracker는 기관에 귀속되는 절차가 현재 어디에 있는지를 말한다. 하나가 다른 하나가 틀렸다는 증거는 아니다.

아카이브된-08개정판(2026년 5월 26일자)은 제안된 새 식별자 계열을w3.org/tbd#에 할당한다. 그 동결된 파일의 해시는cd9d7a31d66dabcb692b2bba3804102b5bba9e3376b999b0cb1404a20ff7f10f이다.

아카이브된-09개정판(8월 21일자)은 그 플레이스홀더를w3.org/2026/08/xmldsig-more#로 대체한다. 또한 추가 제안 식별자와 2026년 네임스페이스를 위한 새 스키마 부록을 포함한 추가 변경도 담는다. 그 해시는09d36d24b05cbc0c1be1579d65fab88e6f9b6cfc13f214d55d4eeed42ad3866b이다.

공개 개정 이력은 5월 26일과 8월 21일의 업로드 날짜를 확인해 준다. 9월 1일까지 작업 그룹 채택, 스트림 지정, 영역 이사 인수인계는 표시되어 있지 않다.

이 시퀀스는 세 가지 사실 이상을 확립하지 않는다. 첫째,-08은 플레이스홀더를 사용했다. 둘째, W3C 페이지는 8월 19일에 수정되었다. 셋째,-09는 8월 21일 할당된 네임스페이스를 사용했다. 이것은 기저 할당 결정의 날짜, 정확히 검토된 개정판, 또는 W3C의 권한이-09의 다른 모든 편집을 자동으로 커버했는지를 확립하지 않는다.

그 정보가 결여된 것이 중요한 이유는, 네임스페이스는 한 문서를 걸어 둘 장소가 아니라 내구성 있는 이름들의 계열을 담기 때문이다. 소프트웨어, 프로파일 또는 조달 규칙이 완전한 URI를 인용하는 순간, 정의 초안이 기관적 이정표에 도달하기 전이라도 이후의 편집 이동은 호환성 기대를 만들어 낼 수 있다.

세 권위가 보이지만 그 인수인계는 보이지 않는다

현재 승인된 앵커는RFC 9231이다. 이 문서는 이전 세대의 추가 XML Security URI를 문서화하며 중요한 구분을 만든다.xmldsig-more식별자는 알고리즘에 대한 공식 W3C 또는 IETF 지위를 함의하지 않는다. 새 초안은 그 방어 논리를 반복한다.

실시간IANA XML Security URIs 레지스트리는 여전히 RFC 9231을 인용하며, 지명된 지정 전문가가 있는 Specification Required 정책 아래 운영된다. 후속 초안이 승인되지 않은 동안에는 예상되는 상태다. 이는 IANA가 늦었거나, 이 작업에 적대적이거나,-09를 즉시 복사해야 한다는 증거가 아니다.

따라서 보이는 세 권위는 서로 다른 행위를 수행한다.

  1. W3C는 자신의 웹 네임스페이스 안에서 URI를 통제하고 지속시킨다.
  2. IETF 문서 절차는 그 URI를 사용하는 사양을 개발하고, 채택하고, 검토하고, 어쩌면 승인할 수 있다.
  3. IANA는 레지스트리 정책을 권위 있는 등록 행위에 적용한다.

개인 초안의 저자는 문서 텍스트를 편집할 수 있다. 그것이 저자를 W3C 네임스페이스 정책의 관리자로 만들지는 않는다. W3C는 URI를 할당할 수 있다. 그것이 W3C를 IETF RFC의 승인 기구로 만들지는 않는다. IANA는 레지스트리를 유지할 수 있다. 그것이 레지스트리 행을 배포 지시로 만들지는 않는다.

그 경계는 이미 개별 기록 안에서 방어 가능하다. 결여된 것은 결합된 이행 지도다. 즉, 2026년 네임스페이스를 편집 가능한 제안 공간에서 동결된 세대로 옮기는 정확한 행위, 그리고 그 행위의 양쪽에서 변경에 대한 규칙이다.

W3C의 지침은 네임스페이스 페이지가 답하지 않는 질문을 던진다

W3C의네임스페이스 할당 지침은/YYYY/MM/...같은 날짜 코드 형식을 인정한다. 이 문서는@w3c/transitions가w3c/ns의 풀 리퀘스트의 일부로 목록에 열거된 W3C 네임스페이스 형식을 할당하고 승인한다고 말한다. 또한 조기 할당이 왜 유용할 수 있는지도 설명한다. W3C는 논의 중에도 안정을 유지하도록 URI를 지속 관리하며, 할당은 승인을 함의하지 않는다.

같은 지침은 지속성에서 멈추지 않는다. 그룹이 자신이 통제하는 네임스페이스가 시간에 따라 바뀔지 바뀌지 않을지, 네임스페이스 문서 안에서 또는 그것에서 명확히 연결된 곳에서 명확히 밝혀야 한다고 말한다.

W3C TAG의 네임스페이스 이름에 관한 파인딩은 이 기대를 정밀하게 만든다. 네임스페이스를 정의하는 사양은 자신의 변경 정책을 명시적으로 밝혀야 한다. 네임스페이스가 불변이 아니라면, 사양은 이름이 어떻게 정의를 받거나 제거될 수 있는지, 그리고 누가 그렇게 하는지를 기술해야 한다. 네임스페이스 문서가 있다면 그 정책은 그곳에 진술되어야 한다. 명시적 진술이 없으면 독자는 그 네임스페이스가 불변이라고 추론할 수 없다.

바로 그 마지막 문장이 두 가지 편한 과잉 주장을 차단한다. 침묵은 W3C가 2026년 네임스페이스를 열어 둘 의도라는 증거가 아니다. 침묵은 또한-09집합이 동결되었다는 증거도 아니다. 그 상태는 공개적으로 추론할 수 없다.

W3C의URI 지속성 정책은 또 하나의 신중한 구분을 더한다. 날짜 코드 자원은 지속성 서약 범위 안에 들지만, 지속 자원은 여전히 수정될 수 있으며 그 이전 상태는 아카이브된다. URI 지속성은 주소 연속성을 보호한다. 그것 자체로는 모든 로컬 이름의 가변성, 제거의 호환성 효과, 변경을 할 권한을 정의하지 않는다.

이것은 할당을 비준수로 선언할 사안이 아니다. 일반 지침은 짧은 페이지에서 찾지 못한 기록을 통해 충족될 수 있으며, 본 기사는 비공개 또는 내부 결정 문서를 알지 못한다. 이것은 W3C의 자체 파인딩이 구현자에게 보라고 말하는 바로 그곳에 정책을 공개하라는 사안이다.

이전 네임스페이스 세대는 결여된 동결 시점을 드러낸다

개정판-09는 네 개의 이전 세대를 나열한다. 2000년 XML Signature 접두어는 “W3C에 의해 동결됨(Frozen by W3C)”이다. 2001년 접두어는 RFC 4051과 함께, 2007년 접두어는 RFC 6931과 함께, 2021년 접두어는 RFC 9231과 함께 동결되었다. 각 행은 동결을 품질 형용사가 아니라 귀속 가능한 상태 전이로 취급한다.

새 2026년 접두어는 그 역사 아래 나타나지만 대응하는 공개 동결 규칙이 없다. RFC가 승인될 때까지 편집 가능한가? W3C 이행 결정까지? 지정 전문가의 조치까지? 초안의 알고리즘 절이 사라지면 로컬 이름을 제거할 수 있는가? 이미 구현체가 인용한 이름은 예약된 채 유지되어야 하는가? 동결 이후의 추가에는 새 날짜 접두어가 필요한가?

이것들은 하나의 답을 위한 논거가 아니다. 이것들은 서로 다른 커뮤니티가 습관으로 답하기 전에 네임스페이스 관리자가 채워야 할 항목들이다. 새 날짜 세대는 초기에 이름을 붙이기는 싸지만, 의존성이 형성된 뒤에 재해석하기는 비싸다.

식별자 구문은 알고리즘 판단과 분리된 채 유지되어야 한다

2026년 초안은XML Signature 1.1과XML Encryption 1.1의 표준적 맥락에 뿌리를 둔다. 그 W3C 권고안들은 XML 보안 구조가 식별자를 소비하는 방식과 식별자 상호운용성이 왜 중요한지를 설명한다. 그것들은 나중에 식별자를 받을 수 있는 모든 알고리즘을 승인하지는 않는다.

초안이 제안하는 IANA 정책은 계속 Specification Required를 사용한다.RFC 8126은 그 정책을 영구적이며 공개적으로 이용 가능한 사양과 전문가 검토를 요구하는 것으로 기술한다. 그 검토 경로는 문서화와 등록 적합성을 시험할 수 있다. 그러나 그것은 여전히 보편적 보안 인증이나 운영자 의무가 아니다.

따라서 본 기사는 HSS/LMS, ML-DSA, SLH-DSA, ML-KEM, FrodoKEM, X-WING, SignatureContext에 대해 어떤 판단도 하지 않는다. 어떤 알고리즘이 안전하거나, 안전하지 않거나, 최종이거나, 필수이거나, 구현되었거나, 광범위하게 배포되었다고 말하지 않는다. 로컬 이름이 비암호학적 기능을 식별한다 해도 거버넌스 문제는 동일할 것이다. 지속적인 식별자 계열에는 대상 문서가 움직이는 동안 자신의 어휘를 변경하는 공개 규칙이 필요하다.

네임스페이스 변경 헌장은 짧을 수 있다

수복은 새 표준화 기구를 요구하지 않는다. 네임스페이스 문서에서 연결된 버전화된 페이지가 열다섯 개 항목으로 헌장을 진술할 수 있다.

헌장은 네임스페이스 URI, 그 날짜 코드 등급, 그리고 할당 결정으로 시작해야 한다. 즉 승인 행위자, 날짜, 공개 풀 리퀘스트 또는 이행 기록이다. 할당 시점의 대상 초안 개정판과 해시를 식별하고, 현재 연결된 개정판은 별도로 식별해야 한다.

허용되는 이정표 이전 변경 등급을 열거해야 한다. 로컬 이름 추가, 기존 이름에 관한 산문 수정, 이름 변경, 제거, 사용 중단 표시는 서로 다른 호환성 효과를 만든다. 기록은 각 행위를 누가 제안할 수 있고 누가 결정하는지, 그리고 기존 인용이 이전 표기를 예약하는지를 말해야 한다.

동결 시점이 되는 행위와 그것을 선언하는 권한을 지명해야 한다. RFC 승인이 세대를 동결한다면 그렇게 말하라. W3C가 더 일찍 또는 더 늦게 동결한다면 그렇게 말하라. 동결 이후 규칙은 새 작업이 같은 접두어 아래의 전문가 검토로 가는지, 정오표로 가는지, 후속 RFC로 가는지, 새 날짜 네임스페이스로 가는지를 설명해야 한다.

그런 다음 기록은 서로 다른 기관 상태를 보존해야 한다. W3C 네임스페이스 관리자, 존재하는 경우의 IETF 문서 등급·그룹·스트림·채택 상태·책임 영역 이사, IANA 레지스트리 정책과 지정 전문가 범위. 식별자 구문을 통제하는 문서와 알고리즘 의미론을 통제하는 출처를 지명해야 한다. 마지막으로 정오표, 대체, 만기, 다음 검토 트리거를 기록해야 한다.

여섯 가지 행위는 하나의 녹색 라벨로 압축되어서는 안 된다. 네임스페이스 할당, 초안 게시, IETF 채택 또는 스트림 지정, RFC 승인, IANA 레지스트리 업데이트, 프로토콜 또는 운영자 배포. 각각은 서로 다른 행위자와 서로 다른 증거 기준을 가진다.

공개 계층은 비공식 논쟁, 보안 민감 구현 보고서, 개인 서신을 노출할 필요가 없다. 독자가 어떤 상태가 존재했는지, 누가 그것을 바꿀 수 있었는지, 어떤 이후 행위가 답을 바꾸었는지를 재구성할 수 있을 만큼의 출처 정보만 필요하다.

이 사안은 부정행위가 아니라 가독성의 문제다

출처 집합에는 무효한 네임스페이스, 불성실함, 장악, 무단 레지스트리 행위, 협력 실패를 보여 주는 것은 아무것도 없다. Strategy 이슈는 공개다. 개인 초안은 공개적으로 아카이브되어 있다. W3C 페이지는 지속된다. IANA의 현재 상태는 정확하다. 초안 자체는 식별자가 기관적 승인을 지니지 않는다는 것을 신중히 부정한다.

그것들은 강점이다. 구성 기록이 이미 존재하기 때문에, 결여된 연결을 더 다루기 쉽게 만든다.

남은 과제는 동적 최신 초안 링크에 헌장의 역할을 수행하게 하는 일을 멈추는 것이다. 발견과 권한은 다른 기능이다. 링크는 독자를 오늘의 텍스트로 데려갈 수 있다. 어제의 권한이 무엇을 커버했는지, 내일의 편집자가 무엇을 바꿀 수 있는지, 어떤 행위가 네임스페이스 세대를 내구적으로 만드는지 설명할 수 있는 것은 버전화된 변경 정책뿐이다.