요약

  • RFC 7865는 SIPREC 녹음 메타데이터 XML 문서를application/rs-metadata+xml로 명시했지만, RFC 7866은 절차와 예제에서 축약된application/rs-metadata를 사용했습니다.
  • 2024년 6월에 에라타 7987이 이 모순을 보고했으며, 현재도Held for Document Update상태로 표시되어 있습니다. 2025년 6월에 Standards Track으로 발행된 RFC 9806은 RFC 7866을 업데이트하면서 모든 기존 표기를 교체하고 이 에라타를 해결한다고 명시합니다.
  • RFC 9806은 2016년 두 문서가 누락했던 IANA 등록도 제공했습니다. 현재 레지스트리 행은application/rs-metadata+xml을 명시하고 RFC 7865와 RFC 9806을 참조합니다.
  • 이 기록들은 현재 명세를 확립합니다. 그러나 어떤 배포된 SRC나 SRS가 어떤 레이블을 수용하는지, 실제 INVITE나 UPDATE가 무엇을 담았는지, multipart 본문이 어떻게 파싱되었는지, 아카이브가 무엇을 저장했는지는 보여주지 않습니다. 교정 보관 증명서는 이러한 사실들을 묶어야 합니다.

네 가지 기록은 일치할 수 있지만 두 대의 기계는 여전히 불일치할 수 있습니다

이 모순은 네 글자 안에 들어갈 만큼 작으면서도 새로운 Standards Track RFC를 요구할 만큼 중요했습니다.

RFC 7865, 즉 2016년 녹음 메타데이터 명세는 참여자 세부사항과 기타 메타데이터를application/rs-metadata+xml유형의 녹음 전용 XML 문서로 기술합니다. 같은 달에 발행된RFC 7866은 세션 녹음 프로토콜을 정의하지만 콘텐츠를 반복해서application/rs-metadata라고 부릅니다. 제9절과 샘플 초기 INVITE, 샘플 스냅샷 요청 모두 짧은 이름을 사용합니다.

이는 본문이 XML인지에 대한 논쟁이 아니었습니다. RFC 7866은 형식에 대해서는 RFC 7865를 참조합니다. 논쟁은 MIME 인식 프로토콜 필드에 담기는 식별자에 관한 것이었습니다. 파서는 동일한 바이트를 이해하면서도 Content-Type이 자신의 디스패치 테이블과 맞지 않으면 본문을 거부할 수 있습니다. 생성기는 유효한 SIP과 유효한 XML을 만들면서도 잘못된 등록 유형을 광고할 수 있습니다.

에라타 7987은 2024년 6월 12일에 이 불일치를 기록했습니다. 현재 페이지는Held for Document Update상태를 보여주고, 기존 문자열과 수정된 문자열을 제시하며, 어느 쪽 원본 RFC도 이 유형을 등록하지 않았다고 밝힙니다. 이 상태 자체가 증거의 일부입니다. 이것은 Verified 에라타와 같은 것이 아니며, 본 기사는 그 명칭을 바꾸지 않습니다.

RFC 9806은 이후의 결정을 제공합니다. 2025년 6월에 IETF Standards Track 문서로 발행되어Updates: 7866을 표시합니다. 이 문서는 RFC 7865가 규범적 메타데이터 정의라고 명시하고, 에라타 7987이 문제를 보고했다고 언급하며, 새 문서가 이를 해결한다고 선언합니다. 그 운용 규칙은 직접적입니다: RFC 7866의 모든application/rs-metadata인스턴스는application/rs-metadata+xml로 교체됩니다.

따라서 기록은 더 이상 현재 이름에 대해 모호하지 않습니다. 배포는 여전히 그럴 수 있습니다.

업데이트가 구현자가 한번 읽었던 페이지를 지우지는 않습니다

RFC 발행은 역사를 보존합니다. 오늘날 원본 RFC 7866 본문을 열면 여전히 제9절과 그림 12, 13에서 짧은 레이블을 볼 수 있습니다. RFC 9806은 그 파일을 조용히 다시 쓰지 않습니다. 대신 결합된 명세를 지금 어떻게 구현해야 하는지 바꾸는 명시적 업데이트를 추가합니다.

이 설계는 가치가 있습니다: 검토자는 원래 주장, 보고된 불일치, 그리고 이후의 해결을 모두 볼 수 있습니다. 동시에 증거가 분산된다는 뜻이기도 합니다. RFC 7866만 읽은 개발자는 오래된 유형을 복사할 수 있습니다. “RFC 7866 지원”만 저장하는 컴플라이언스 인벤토리는 제품이 어느 해석을 구현하는지 드러내지 못합니다. 현재Held상태만 기록하는 에라타 스크래퍼는 문제가 해결되었다고 말하는 이후의 RFC를 놓칠 수 있습니다. 레지스트리 점검은 올바른 행을 찾을 수 있지만 어느 릴리스가 그것을 실제로 소비했는지 증명하지 못합니다.

이는 아카이브 모델의 결함이 아닙니다. 문서 상태를 구현 상태와 분리해 유지해야 하는 이유입니다.

네 가지 관련 기록은 서로 다른 질문에 답합니다. RFC 7865는 메타데이터 문서 유형이 의도된 것이 무엇인지 말합니다. RFC 7866은 불일치하는 식별자가 유선 절차에 어디서 들어갔는지 보여줍니다. 에라타 7987은 보고서와 그 처분 상태를 보존합니다. RFC 9806은 공식 업데이트와 등록을 제공합니다. 그 어느 것도 실행 중인 소프트웨어의 목록이 아닙니다.

IANA 행이 네임스페이스 공백을 메웁니다

RFC 9806은 2016년 두 RFC가 미디어 유형을 등록하지 않았다고 말한 뒤 누락된 템플릿을 제공합니다. 등록은 유형application, 서브타입rs-metadata+xml, 필수 또는 선택 매개변수 없음, 그리고RFC 7303에 따른application/xml과 정렬된 인코딩 고려사항을 정의합니다. 세션 녹음 클라이언트와 세션 녹음 서버를 애플리케이션으로 식별하고, 의도된 사용을 COMMON으로 명시하며, 변경 관리 권한을 IETF에 둡니다.

2026년 9월 20일에 캡처된 IANA Media Types 레지스트리는application/rs-metadata+xml을 RFC 7865와 RFC 9806 참조와 함께 나열합니다. 이 행은 정밀한 조정 기능을 수행합니다: 이름에 공개적인 장소를 부여하고, 그것을 정의하고 교정하는 명세를 참조합니다.

+xml접미사는 유용한 기계 판독 가능 사실도 담고 있습니다. RFC 7303은 이 접미사가 일반 XML 인식 소프트웨어가 XML MIME 엔터티를 인식하게 해준다고 설명합니다. 하지만 그것이 구현에게 문서가 SIPREC 스키마를 준수하는지, 올바른 녹음 세션에 속하는지, 스냅샷과 부분 업데이트의 일관된 시퀀스를 담는지를 알려주지는 않습니다. 구문 계열과 애플리케이션 의미는 여전히 다른 계층입니다.

IANA 할당이 파서를 설치하지도 않습니다. 레지스트리는 제품 릴리스가 새 토큰을 추가했는지, 구성이 그것을 활성화했는지, 프록시가 그것을 다시 썼는지, 아카이브가 내부 값으로 정규화했는지 보여줄 수 없습니다. 등록은 네임스페이스 공백을 메웁니다. 배포 공백은 메우지 못합니다.

교정은 MIME 봉투 안에서 운영적으로 작동합니다

RFC 7866은 유선 표면을 구체화합니다. SRC는 INVITE 또는 UPDATE에서 전체 스냅샷이나 부분 업데이트를 보낼 수 있습니다. 하나의 SIP 메시지가 SDP 오퍼와 메타데이터를 모두 담으면 본문은multipart/mixed여야 합니다: 하나의 하위 파트는 SDP를, 다른 파트는 녹음 메타데이터를 담습니다. 메타데이터 파트는Content-Disposition: recording-session을 사용합니다. 경계, 파트 헤더, XML 본문과 SDP 레이블이 함께 SRS가 받는 것을 결정합니다.

RFC 9806은 예제에 표시된 값들을 포함한 관련 미디어 유형 표기를 변경합니다. 그러나 실제 상호운용성 증명은 컨포먼스 문서 속 수정된 문자열만으로는 충분하지 않습니다. 메서드, 다이얼로그 및 트랜잭션 식별자; 외부multipart/mixed헤더와 경계; 메타데이터 파트의 정확한 Content-Type과 Content-Disposition; 메타데이터 본문의 경계 해시; XML 네임스페이스; 콘텐츠가 전체 스냅샷인지 부분 업데이트인지; 그리고 피어의 파싱 결과를 보존해야 합니다.

그 결과가 중요한 이유는 RFC 7866이 SRS에 상태 유지 의무를 부여하기 때문입니다. SRS는 부분 업데이트의 시퀀스를 따라야 합니다. 내부 상태가 손실되면 새 전체 스냅샷을 요청할 수 있습니다. 메타데이터 구문이나 의미 오류를 감지하면 동일한 실패를 반복하는 대신 녹음 세션을 종료할 수 있습니다. SIP 다이얼로그 어딘가의 2xx 응답을 이 메타데이터 체인이 수용되었다는 증명으로 승격시킬 수 없습니다.

마찬가지로 녹음 파일은 결정적 증거가 아닙니다. RFC 7866은 저장과 재생을 프로토콜의 범위 밖에 둡니다. 메타데이터가 지연되거나, 억제되거나, 거부되거나, 정규화되거나, 레거시 레이블로 저장되는 동안 미디어가 녹음되었을 수 있습니다. 교정 보관을 증명하려면 아카이브는 자체 증거가 필요합니다: 어떤 레이블을 유지했는지, 본문을 어떻게 색인했는지, 그리고 이후 어떤 재생 또는 내보내기 경로가 그것을 해석했는지.

호환성은 마지막 미교정 노드를 숨길 수 있습니다

이중 수용 파서는 합리적인 마이그레이션 도구일 수 있습니다.application/rs-metadata와application/rs-metadata+xml을 모두 수용하면 생성기가 교정된 이름으로 이동하는 동안 구형 피어를 계속 작동시킬 수 있습니다. 그러나 RFC 9806은 그 정책을 규정하지 않으며, 호환성은 두 번째 문제를 만듭니다: 성공이 덜 정보적이 됩니다.

모든 서버가 무기한 두 레이블을 수용하면, 구형 클라이언트는 보이지 않은 채 남을 수 있습니다. 게이트웨이가 오래된 이름을 새 이름으로 다시 쓰면, 다운스트림 원격측정은 소스가 그대로인데도 플릿이 교정된 것처럼 보이게 만들 수 있습니다. 서버가 두 값을 로깅 전에 정규화하면, 운영자는 잔존 레거시 트래픽이 존재한다는 유일한 신호를 잃습니다. 출처 보존 원격측정 없는 호환성은 전환을 영구적인 사각지대로 만듭니다.

결정은 단순히 “엄격” 대 “관용”이 아닙니다. 운영자는 방향과 시간을 정의해야 합니다. 새 생성기는 교정된 레이블만 내보내면서 파서는 임시로 둘 다 수용할 수 있습니다. 레거시 별칭은 지명된 피어나 코호트로 제한될 수 있습니다. 재작성은 수신된 값과 전달된 값을 따로 기록할 수 있습니다. 퇴역은 달력 추측이 아니라 관측된 트래픽에 따라야 합니다. 각 예외에는 소유자와 종료 기준이 필요합니다.

교정 보관 증명서

제안된 증명서는 Daniel Kade의 편집 통제이며, RFC 9806 필드가 아니고 IETF, RFC Editor 또는 IANA의 요구사항도 아닙니다.

문서 체인으로 시작합니다: 두 원본 절 주장에 대한 고정 참조; 에라타 7987의 ID, 보고일, 상태 및 교정; RFC 9806의 발행 범주, 업데이트 관계 및 교체 규칙; 그리고 날짜가 기록된 IANA 레지스트리 항목과 템플릿 해시.

그 다음 구현을 묶습니다: SRC와 SRS 제품, 버전, 빌드, 파서 및 생성기 모듈, 구성 세대, 그리고 각 방향에서 수용하고 내보내는 정확한 레이블. 레거시 별칭이 거부되는지, 수용되는지, 정규화되는지, 재작성되는지 기록하고, 그 동작을 보이게 만드는 규칙을 식별합니다.

트랜잭션에 대해서는 SIP 메서드와 경계 식별자, Accept와 Content-Type 값, multipart 경계, Content-Disposition, 메타데이터 본문 해시, 네임스페이스, 스냅샷/업데이트 상태, SDP 레이블 바인딩과 피어 결과를 유지합니다. 모든 결과를 “녹음 성공”으로 합치는 대신 거부 클래스, 스냅샷 요청 또는 세션 종료를 저장합니다.

아카이브 경로를 결합합니다: 저장된 레이블, 색인 키, 정규화 규칙, 내보내기 표현과 재생 결과. 배포 코호트, 이전/새/미확인 트래픽 수, 카나리아 결과, 호환성 창, 음성 테스트, 롤백 트리거와 소유자를 추가합니다. 마지막으로 별칭을 퇴역시키는 결정을, 잔존 레거시 트래픽과 수용된 예외와 함께 보존합니다.

증명서는 교정을 더 규범적으로 만들지 않습니다. 채택을 검토 가능하게 만듭니다. 발행은 규칙이 존재함을 증명합니다. 증명서는 규칙이 어디서 작동했는지 보여줍니다.

증거 경계

소스 기록은 모순, 에라타, 업데이트와 레지스트리 상태를 확립합니다. SIPREC 제품이나 배포의 인센서스도, 벤더 지원 매트릭스도, 오래되거나 새로운 레이블의 측정된 점유율도, 불일치로 귀속된 보고된 인시던트도 담고 있지 않습니다. 명명된 구현이 낡았거나 비준수라고 여기서 비난하지 않습니다.

이 기사의 리스크 경로는 관측된 실패가 아니라 테스트 가능한 시나리오입니다. 프로토콜의 가시적인 디스패치와 상태 표면에서 따르는 것입니다: 정확한 미디어 유형 토큰, multipart 프레이밍, XML 파싱, 업데이트 시퀀스와 아카이브 처리. 배포는 RFC 9806의 존재를 증거의 대체물로 취급하기보다 이들을 현지에서 검증해야 합니다.

출처