요약

  • Verified(확인됨) 상태의 정오표는 RFC에 연결된, 검토를 거친 정확한 수정 기록입니다. RFC Editor는 정오표가 TXT, PDF 또는 XML 출판 형식에 반영되지 않는다고 명시하고 있습니다.
  • IESG는 정오표를 문서 승인 시점에 이미 존재하던 오류로 제한합니다. 새로운 사고, 중대한 프로토콜 변경, 의도된 합의에 대한 변경은 관련 표준 절차로 되돌아가야 합니다.

문서 곁에 머무는 수정

구현자가 RFC에서 모순을 만났다고 가정해 봅시다. 한 단락은 어떤 값을 허용하는데, 뒤에 나오는 알고리즘은 그 값을 거부하는 것처럼 보입니다. 정오표 페이지에는 원문 텍스트, 수정된 텍스트, 그리고 Verified 상태가 담긴 보고서가 있습니다. 실무에서는 수정된 텍스트가 처음부터 RFC에 있었던 것처럼 다루고 싶은 유혹이 있습니다.

그러나 이 지름길은 중요한 사실을 잃게 만듭니다. 출판된 문서는 특정 시점에 검토, 승인, 제작을 통과한 내용을 기록합니다. 정오표는 그 기록의 결함에 대해 나중에 내려진 판단을 기록합니다. 둘 다 중요합니다. 전자는 표준의 출처를 제공하고, 후자는 문자 그대로의 해석이 구현자를 오도할 수 있음을 경고합니다.

RFC Editor의 현재 지침은 이 구분을 명확히 합니다. 접수된 정오표는 문서의 정보 표면에 부착됩니다. Verified 보고서는 검토를 거쳤으며 정확한 것으로 간주됩니다. 그럼에도 이 수정 사항은 일반적인 TXT, PDF 또는 XML 판본에 삽입되지 않습니다. 독자는 연결된 수정 계층을 직접 확인해야 합니다.

이는 행정적 고집이 아닙니다. 눈에 보이는 이음선 없이 집단적 결정을 다시 쓰는 일을 막는 통제 장치입니다.

네 가지 상태는 네 가지 다른 행위

“정오표가 있다”는 표현은 엔지니어링이나 조달 판단에는 너무 거칠습니다. 실제로 무슨 일이 일어났는지는 상태가 결정합니다.

Reported는 주장이 대기열에 들어왔다는 뜻입니다. 아직 책임 있는 검증자의 판단을 받지 못했습니다. 보고서는 맞을 수도, 틀릴 수도, 불완전할 수도, 그리고 기존의 이견을 다시 열려는 시도일 수도 있습니다.

Verified는 보고서가 해당 기준에 따라 유효하며 구현자와 운영자가 볼 수 있어야 함을 의미합니다. 가장 강한 정오표 상태지만, 그 권한은 여전히 수정에 국한됩니다. 검토자에게 프로토콜을 재설계할 일반적 권한을 주지는 않습니다.

Rejected는 보고서가 무효이거나, 중복이거나, 이 수정 채널로 처리하기에 너무 방대하다는 뜻입니다. IESG는 대체 또는 갱신 RFC에 담겨야 할 중대한 변경을 특히 이 경계의 바깥쪽에 둡니다.

Held for Document Update는 해당 사안이 현재 RFC의 필요한 수정은 아니지만, 향후 개정에서 고려될 수 있음을 뜻합니다. 보류는 기관의 기억이지 운용상의 문구가 아닙니다. 이를 이미 승인된 것처럼 다루면, 미해결 제안이 검증된 결함과 같은 데이터베이스에 나타나는 것만으로 힘을 얻게 됩니다.

이 상태들은 간결한 결정 장부를 이룹니다: 주장, 수용된 수정, 기각된 수정, 연기된 검토. 이를 하나의 “최신 텍스트” 필드로 뭉개면 분류에 담긴 판단 근거가 사라집니다.

검증 권한은 출판 스트림을 따른다

RFC는 서로 다른 스트림을 통해 만들어집니다. IETF, IAB, IRTF, Independent Submission, Editorial 스트림은 서로 다른 승인 주체와 목적을 갖습니다. 따라서 RFC Editor의 검증 지침은 해당 RFC를 만든 스트림에 따라 검토 주체를 배정합니다.

IETF 스트림의 기술 정오표는 저자, 워킹 그룹 의장, Area Director에게 전달됩니다. Area Director는 검토를 위임할 수 있지만 처리 책임은 유지합니다. Editorial 보고서는 RFC Editor가 1차로 처리하며, 필요할 때 Area Director가 개입합니다.

이 구분은 제작 전문성과 기술적 권한이 뒤섞이지 않게 합니다. 제작 주체는 문장 부호와 렌더링 문제를 알아볼 수 있습니다. 그러나 수정 데이터베이스를 운영한다는 이유만으로 프로토콜 정책 권한을 얻어서는 안 됩니다. 반대로 기술 검토자가 작은 수정 양식을 통해 원래 행동을 정한 커뮤니티를 우회해서도 안 됩니다.

따라서 검증자의 이름, 날짜, 근거, 스트림은 증거의 일부입니다. 누가, 어느 스트림에서, 어떤 의도에 대하여 검증했는지 모른 채의 “Verified”는 불완전한 거버넌스 주장입니다.

원래 의도가 상한선이다

현재 유효한 2021년 IESG 성명이 결정적 기준을 제공합니다. 정오표는 RFC가 출판될 당시 존재하던 오류를 다룹니다. 새로운 기능, 선호되는 설계를 바꾸는 후발 발견, 승인된 결과에 대한 반대는 대체 문장의 형태로 표현할 수 있다는 이유만으로 자격이 없습니다.

IESG는 원래 의도와 일치하는 명확한 기술적 해결은 Verified로 처리할 수 있다고 허용합니다. 해결이 불명확하거나 추가 논의가 필요하면 보류에 두어야 합니다. 승인된 합의에서 프로토콜 동작을 벗어나게 하는 변경은 일반적으로 Rejected되어야 합니다. 서로 다른 IANA 등록 절차 같은 절차 변경은 의도된 합의를 바꾸게 된다면 정오표를 통해 들어와서는 안 됩니다.

이것은 편집 위생으로 위장된 헌법적 제한입니다. 좁은 양식은 “원문”과 “수정문”을 요구하지만, 텍스트가 작다고 정책적 변경도 작은 것은 아닙니다. 단 한 단어가 요구사항을 뒤집을 수 있습니다. 코드 포인트 범위 하나가 확장 권한을 재분배할 수 있습니다. 기본값 하나가 운영 리스크를 송신자에서 수신자로 옮길 수 있습니다.

따라서 검토자는 제안된 문구 이상의 것에서 의도를 재구성해야 합니다. 워킹 그룹 토론, Last Call, 투표 입장, 상호운용성 기대, 주변 알고리즘 모두 중요할 수 있습니다. 그 증거가 명확한 수정을 확립하지 못한다면, 정오표 채널은 확실성을 만들어내는 대신 의심을 보존해야 합니다.

파일을 다시 발행하는 것은 의미를 몰래 바꾸는 것이 아니다

출판 모델은 2025년과 2026년에 더 정교해졌습니다. RFC 9720은 확정 RFCXML 판본과 렌더링된 출판 판본을 통제된 좁은 사유로 재발행할 수 있도록 허용합니다. 2026년 2월에 RFC 9280을 대체한 RFC 9920은 안정성을 역사적 속성으로 유지하면서 재발행을 인정합니다.

이 허용은 모든 검증된 정오표를 의미 텍스트에 접어 넣는 면허가 아닙니다. RFC 9720은 확정 판본의 변경은 원래 RFC가 표현한 의미를 보존해야 한다고 규정합니다. 스키마 진화, XML 오류, 제작 도구 변경을 재발행 사유로 명시합니다. 이전 판본은 보존되어야 하며, 재발행에는 공개 기록과 사유가 있어야 합니다.

핵심 구분은 그릇을 수리하는 것과 그릇이 담고 있는 결정을 바꾸는 것 사이에 있습니다. 렌더러가 도식을 잘라내는 것을 멈출 수 있습니다. XML 마이그레이션이 문자를 정확히 보존할 수 있습니다. 표현이 시리즈 전반에서 일관될 수 있습니다. 그러나 프로토콜 동작에 대한 새 규칙은 여전히 그런 규칙을 만들 수 있는 권한을 필요로 합니다.

이 이중 트랙 구조—충실한 출판을 위한 통제된 재발행, 검토된 수정을 위한 연결된 정오표—는 사용성과 역사적 책임성을 모두 보호합니다. 이 둘을 합치면 두 구현자가 서로 다른 의미를 읽었는지, 아니면 단지 다른 렌더링을 읽었는지 구별하기 어려워집니다.

구현자에게 필요한 이중 기록 방법

진지한 구현은 RFC 번호만 인용해서는 안 됩니다. RFC의 상태, 이후 RFC가 갱신하거나 대체하는지 여부, 사용된 출판 판본, 명시된 기준일 기준의 관련 정오표를 기록해야 합니다.

Verified 정오표는 직접적인 엔지니어링 처리를 받을 자격이 있습니다. 테스트는 구현이 수정을 따르는지 보여야 하고, 릴리스 노트는 아직 수정 전 텍스트를 따르는 배포 상대가 있을 때의 호환성 결과를 설명해야 합니다. 보안에 민감한 수정은 보관 문서가 손대지 않은 채로 남아 있더라도 즉각적인 완화 조치를 요구할 수 있습니다.

보류된 보고서에는 다른 대응이 맞습니다. 이는 향후 설계 검토에 정보를 주고 모호한 영역을 표시할 수 있지만, 자동으로 적합성 실패로 전환되어서는 안 됩니다. 기각된 보고서도 유용할 수 있습니다. 어떤 제안된 해석이 검토되었으나 거부되었음을, 또는 요청된 변경에 더 넓은 절차가 필요함을 보여주기 때문입니다.

이 방법은 대칭적인 두 오류를 피합니다. 정오표를 무시하는 것은 보관소를 무오류로 취급하는 것이고, RFC를 보이지 않는 병합 판본으로 대체하는 것은 수정 관리자를 입법부로 취급하는 것입니다. 좋은 구성 관리는 기본 결정과 수정 판단을 독립적으로 식별 가능하게 유지합니다.

출판 이후의 진실을 위한 얇은 공통 장부

Lu Heng의 거버넌스 모델은 최소한의 공통 기록, 유능한 주체의 현지 결정, 모든 권한에 대한 중앙 주장이 아니라 자발적 채택을 통한 미래 변화를 선호합니다. 정오표 체계는 그 술어가 좁게 유지될 때 이 구조에 부합합니다.

공통 계층은 RFC, 섹션, 원래 구절, 제안된 수정, 보고서 유형, 상태, 검증자, 근거, 날짜를 식별할 만큼의 구조만 있으면 됩니다. 그러면 구현자는 수정이 자신의 소프트웨어에 미치는 영향을 결정하고, 운영자는 완화의 시급성을 결정하며, 워킹 그룹은 새 RFC가 필요한지를 결정할 수 있습니다.

공유 기록은 모든 Verified 항목이 보편적으로 배포되었다고 선언해서는 안 됩니다. Held 항목을 의무로 변환해서는 안 됩니다. 비활성 워킹 그룹의 침묵을 합의의 증거로 추론해서는 안 됩니다. 이들은 별도의 증거를 요구하는 별도의 주장입니다.

이 절제가 수정 체계를 더 강하게 만듭니다. 그 권한은 무엇이 보고되었고 책임 있는 절차가 그것을 어떻게 분류했는지를 정확히 말하는 데서 옵니다. 보관 문서 곁의 메모가 문서의 역사를 지워버렸다고 가장하는 데서 오는 것이 아닙니다.

출처