요약

  • RFC 3969는 한 철자가 두 가지 의미를 갖는 상황을 막기 위해 모든 SIP/SIPS URI 매개변수 이름을 두 스킴 모두에 예약했다. 이러한 짝 예약은 해당 매개변수가 양쪽에 적용된다는 것을 증명하지 않았다.
  • 이 문서는 자신의 정책을 “Specification Required”라고 부르면서 표준 트랙 RFC를 요구했다. RFC 5727은 이후 이 모순을 지적하고 의도된 규칙이 Standards Action임을 명확히 했다.

RFC 3969에서 가장 계시적인 문장은 겉보기 역설이다. 모든 매개변수 이름은 SIP URI와 SIPS URI 양쪽에 등록되어야 했다. 그러나 문서는 곧바로 일부 매개변수는 두 스킴 중 하나에는 적용되지 않을 수 있다고 경고했다. 같은 이름이 두 곳을 차지하지만, 그 메커니즘이 실제로 어디에서 작동하는지는 정의 명세만이 말할 수 있었다.

이 선택은 기능 문제가 아니라 네임스페이스 문제를 해결한 것이다. 어떤 이름이 SIP에서만 보호된다면, 다른 저자가 SIPS에서 다른 의미로 그 이름을 재사용할 수 있었다. 그러면 파서, 로그, 프로비저닝 시스템 또는 사람 조사자는 같은 철자를 보고 그 의미가 무엇인지 추측해야 했다. 두 스킴 모두에 걸쳐 이름을 예약함으로써 레지스트리는 그 모호함이 설치된 관행이 되기 전에 차단했다.

이 경계는 데이터베이스 내보내기에서 쉽게 사라진다. 짝을 이룬 행은 짝을 이룬 지원처럼 보일 수 있다. 그렇지 않다. 예약은 누가 이름을 할당할 수 있는지를 통제하고, 적용 가능성은 정의된 동작이 특정 스킴에 속하는지를 통제한다. 구현 지원, 정책 승인, 성공한 세션은 그보다 더 하류에 있다.

일곱 개 이름이 이 설계를 드러냈다

RFC 3261은 새로운 SIP 및 SIPS URI 매개변수와 값을 허용했지만 이를 위한 IANA 레지스트리를 만들지 않았다. RFC 3969는 2004년 12월에 이 공백을 채웠다. 초기 표에는 일곱 개 이름이 있었다:comp,lr,maddr,method,transport,ttl,user.comp는RFC 3486을 가리켰고, 나머지는 처음에 RFC 3261을 가리켰다.

행에는 이름, 값이 미리 정의된 집합에서 오는지 여부를 나타내는 플래그, 참조가 담겼다. 플래그가Yes인 경우 레지스트리는 전체 어휘를 담고 있다고 가장하지 않았다. 구현자를 인용된 모든 RFC로 안내했다. 예컨대 현재의IANA SIP 매개변수 레지스트리는transport에 대해 RFC 3261과RFC 7118을 모두 인용한다. 이 행은 스스로 완결된 문법이 아니라 권위로 이어지는 관리되는 지도다.

레지스트리가 등록된 이름과 값을 “예약어(reserved words)”라고 부른 이유가 바로 여기 있다. 로컬 매개변수가 존재할 수 있었지만, 미래의 공개 할당과 충돌할 위험을 안고 있었다. 등록된 텍스트는 정의 RFC와 일관되게 사용되어야 했고, 사적 정의는 그것과 충돌할 수 없었다. 레지스트리에는 벤더 확장 트리가 없었다:RFC 3427은 이미 SIP 확장이 위험한 복잡성이나 보안 피해를 더할 수 있다고 경고한 바 있어, 공개 경로는 RFC 문서화를 요구했다.

이 절차는 독립 구현들이 같은 철자에 우연히 수렴하는 사고를 막았다. 두 제품이 참조된 동작을 구현했다는 것을 인증하지도 않았고, SIPS를 단순히 “SIP에 문자 하나 더한 것”으로 만들지도 않았다.RFC 5630은 이후 SIPS 처리와 보안 기대를 명확히 했고,RFC 3263은 서버 위치와 전송 선택을 기술했다. 이러한 운영 규칙은 레지스트리의 짝 예약만으로 재구성할 수 없다.

정책 레이블이 스스로의 요구와 모순되었다

RFC 3969는 더 미묘한 역사적 결함도 그대로 남겼다. 4.2절은RFC 2434의 “Specification Required” 레이블을 사용했다. 그 다음 문장은 매개변수가 표준 트랙 RFC로 정의되어야 한다고 요구했다. 이 둘은 교환 가능한 기준이 아니다. Specification Required는 영구 공개 명세와 전문가 검토를 허용하고, Standards Action은 표준 절차를 통한 승인을 요구한다.

6년 뒤RFC 5727은 이 충돌을 직접 지명했다. 등록 정책 범주에 대한 오해에서 모순이 비롯되었으며, 의도된 요구는 Standards Action이었다고 밝혔다. 현재 IANA 페이지는 이제 Standards Action을 표시한다. 이후 구식 정책 어휘를 대체한RFC 8126은 이 구분이 왜 중요한지 설명하는 데 도움이 된다: 레지스트리 정책은 서로 다른 결정 권한, 검토 부담, 문서화 기준을 할당한다.

이 정정은 레지스트리가 사용 불가능했다는 증거가 아니다. 거버넌스에도 계보가 있다는 증거다. 현재 셀은 현재의 행정 질문에 답한다. 2004년 RFC는 원래 텍스트가 무엇을 말했는지에 답한다. RFC 5727은 둘이 왜 다른지를 설명한다. 이 층 중 하나를 제거하면 이야기는 더 단정해지지만 정확성은 떨어진다.

유지 관리되는RFC Editor 기록,정오표 검색,IETF Datatracker 이력은 상태, 보고된 정정, 문서 이력에 대해 서로 다른 기록을 제공한다. 어느 것도 배포를 측정하지 않는다.RFC 3986은 일반 URI 프레임워크를 제공하고,RFC 6648은 이후 접두사를 표준 상태의 약칭으로 쓰는 것을 경고했다. 함께 이 같은 원칙을 강화한다: 철자, 할당, 적용 가능성, 성숙도, 관찰된 동작은 서로 다른 사실이다.

하나의 관찰된 매개변수를 읽는 방법

정확한 URI 스킴과 철자에서 시작하라. 해당 시점에 존재했던 레지스트리 행을 찾아라. 첫 번째 것뿐 아니라 모든 참조를 따라가고, 정의 구문, 적용 가능성, 보안 절을 읽어라. 그다음 구현 증거를 확보하라: 파서 지원, 구성, 트랜잭션 동작, 최종 결과. 성공한 통화는 매개변수가 중요했다는 사실을 소급적으로 증명할 수 없고, 할당된 이름은 시스템이 그것을 이해할 것이라는 사실을 예견적으로 증명할 수 없다.

따라서 RFC 3969의 짝 예약은 보수적인 엔지니어링이었다. 하나의 의미를 보존하기 위해 두 개의 네임스페이스 슬롯을 사용했다. 비용은 실제 적용 가능성보다 넓어 보이는 표였다. 해결책은 표에서 동작을 추론하는 것이 아니라, 이름에서 스킴으로, 참조로, 구현으로, 결과로 이어지는 사슬을 유지하는 것이었다.

출처