요약

  • RFC 3968은 RFC 3261이 만들지 않았던 IANA 레지스트리를 만들어 SIP 헤더 필드 파라미터를 해당 필드, 파라미터 이름, 사전 정의 값 여부 표시, 그 의미를 정의한 RFC들과 결합했다.
  • 등록은 우연한 네임스페이스 충돌을 줄이고 문서적 출처를 확립했다. 그러나 엔드포인트 지원, 런타임 이해, 성공적 협상, 승인, 안전한 동작 또는 통화 결과를 증명하지는 못했다.

프로토콜 트레이스에서 등록된 이름은 안심이 되어 보인다. 철자가 정확하고, 공개 레지스트리에 존재하며, RFC가 연결되어 있다. 이러한 관찰은 유용하지만, 운영자가 흔히 묻는 질문보다 좁은 질문에 답한다. 이것들은 커뮤니티가 토큰과 문서화된 목적 사이의 결합을 기록했다는 사실을 보여준다. 그러나 이 특정 엔드포인트가 그 결합을 알고 있거나 문서화된 동작을 수행했다는 것은 보여주지 못한다.

RFC 3968은 2004년 12월에 공개되었으며, 행정적 누락에서 출발했다.RFC 3261은 확장이 새로운 SIP 헤더 필드 파라미터와 파라미터 값을 정의하는 것을 허용했지만, 이를 위한 IANA 레지스트리를 만들지는 않았다. RFC 3968은 누락된 이 조정 계층을 보완하고 SIP 및 관련 사양에서 이미 정의된 파라미터들로 레지스트리를 채웠다.

이 복구가 중요했던 이유는 텍스트 네임스페이스가 조용히 실패할 수 있기 때문이다. 서로 다른 두 독립 구현자가 서로 다른 기능에 같은 짧은 단어를 선택할 수 있다. 메시지는 구문상 그럴듯하게 유지되지만, 양쪽이 같은 토큰에서 서로 다른 의미를 읽어낸다. RFC 3968은 등록이 헤더 필드, 파라미터 이름, 파라미터가 사전 정의된 값 집합을 받는지 여부, 그리고 정의를 담은 RFC 또는 RFC들을 식별하도록 요구했다. 선언된 목표는 독립 구현 간의 상호운용성과 우연한 네임스페이스 충돌 방지였다.

이는 거버넌스의 성과이지, 기능 광고가 아니다.

이름은 자신이 속한 필드 안에서만 고유했다

RFC 3968은 하나의 평평한 전역 사전을 만들지 않았다. 같은 파라미터 이름이 서로 다른 헤더 필드에 나타나는 것을 허용했다. 금지한 것은 같은 헤더 필드에서 같은 이름을 가진 두 파라미터였다. 따라서 레지스트리 항목의 식별자는 맥락에 따라 달라졌다. 헤더 필드 더하기 파라미터 이름, 그 다음 정의 참고 문서 순이었다.

이 구분은 근거를 어떻게 보존해야 하는지 바꾼다.q,algorithm,tag또는expires만 남기는 로그는 식별자의 일부를 버린 것이다.Accept아래의q는Contact또는Security-Client아래의q와 자동으로 같은 등록 항목이 아니다. 맨 파라미터 철자만 일치하는 검색 결과는 사실상 정확하면서도 잘못된 의미 대상을 가리킬 수 있다.

등록된 항목은 예약어가 되었다. 구현은 이를 정의 RFC와 일관되게 사용해야 했고, 사설 또는 로컬 정의 파라미터는 이들과 충돌할 수 없었다. 그러나 RFC 3968은 미등록 파라미터를 금지하지 않았다. 위험하다고 경고만 했다. 나중에 어떤 RFC가 같은 이름을 다른 목적으로 등록하면, 사설 배포는 자신의 이전 성공이 막아주지 못한 충돌에 노출될 수 있다.

이 경고는 관찰된 기능과 내구성 있는 권한을 구분한다. 사설 파라미터는 양쪽이 로컬 지식을 공유하기 때문에 오늘 동작할 수 있다. 그 동작하는 교환은 그 순간의 로컬 합의를 증명할 뿐, 이름에 대한 전역적으로 보호되는 권리를 증명하지 않는다. 반대로 등록은 공개 권리를 확립하지만, 오래된 소프트웨어가 그것을 학습했는지에 대해서는 아무것도 말하지 않는다.

행은 정의를 가리켰을 뿐, 정의 자체가 아니었다

일부 파라미터는 문법 범위 내에서 임의의 값을 받았다. 다른 파라미터는 사전 정의된 토큰만 받았다. RFC 3968은 후자를Yes열로 표시했지만, 모든 값 집합마다 별도의 하위 레지스트리를 만드는 것은 의도적으로 피했다. 대신 값을 참조로 등록했다. 행은 원래 RFC를 인용하고, 값을 추가한 이후 RFC들을 이중 괄호로 표시했다.

구현은 레지스트리 스냅샷을 완전한 파서 테이블로 취급할 수 없었다. 적용되는 모든 참고 문서를 따라가 구문, 의도된 용도, 의미론, 유효한 값 집합을 복원해야 했다. 참고 문서 없이 복사된 테이블은 등록을 유용하게 만든 권한 자체를 잃었다. 오래된 복사본은 완전해 보이는 모습을 유지하면서 이후 추가된 값을 놓칠 수도 있다.

따라서 RFC 요구 사항은 실질적이었다. 사양은 구문, 목적, 의미론을 설명하고 보안을 논의해야 했다. RFC 3968은 당시RFC 2434가 정의한IETF Consensus정책을 사용했으며, 정의 RFC가 표준 트랙일 필요는 없었다. 이후RFC 8126의 레지스트리 정책 프레임워크는 등록을 네임스페이스 내에서 목적에 값을 할당하는 것으로 설명한다. 이 정식화는 여전히 유용하다. 할당은 공개 결합을 지배한다. 코드를 설치하거나 동작을 승인하지는 않는다.

협상은 메시지에서 일어났지, IANA에서 일어나지 않았다

SIP에는 이미 일부 런타임 확장 지원을 표현하는 메커니즘이 있었다. RFC 3261은Supported,Require,Proxy-Require,Unsupported및 응답 코드 420을 정의했다. 사용자 에이전트는 옵션 태그를 광고하거나, 피어가 확장을 이해할 것을 요구하거나, 지원되지 않는 요구 사항을 식별하는 거부를 받을 수 있었다. 이 메시지들은 엔드포인트가 만들어낸 트랜잭션 근거였다.

파라미터 레지스트리는 다른 종류의 근거를 만들었다. 그것은 이름이 귀속 가능한 정의를 갖는다는 것을 확립했다. 그러나 엔드포인트가Supported를 내보내거나,Require를 받아들이거나, 파라미터를 파싱하거나, 정책을 적용하거나, 통화를 완료하도록 만들지는 않았다. 지원 광고조차 결과보다 좁게 남는다. 소프트웨어는 기능을 인식하면서도 특정 요청에서 그 사용을 거부하거나 다른 이유로 나중에 실패할 수 있다.

RFC 3261은 또한 서버가 이해하지 못하는 헤더 필드를 무시하고, 요청에 필요한 필드를 조건으로 처리를 계속하도록 요구했다. 이 규칙은 확장성을 가능하게 했지만, 패킷의 생존을 모호하게 만든다. 메시지가 엔드포인트를 통과했다는 사실은 모든 익숙하지 않은 필드나 파라미터가 처리에 영향을 주었다는 것을 증명하지 않는다. 성공적인 전달은 의미론적 무관심과 공존할 수 있다.

그래서 운영자의 근거 사슬에는 여러 영수증이 필요하다. 레지스트리 항목, 정의 RFC, 엔드포인트 능력, 정확한 트랜잭션, 관찰된 처리, 최종 서비스 결과. 어느 것도 다음의 권한을 물려받지 않는다.

접두사는 수명 주기 레이블로 실패했다

주변의 SIP 변경 과정은 RFC 3968이 문서화를 고집한 이유를 보여준다.RFC 3427은 새로운 SIP 기능이 보안을 손상시키거나 복잡성을 크게 높일 수 있다는 우려를 기술했다. RFC 3427은 예비, 사설 또는 독점P-헤더 필드를 위한 감독된 경로를 만들고 그 제한된 범위를 이름 속에 드러나게 유지하려 했다.

경험은 그 경계를 보존하지 않았다.RFC 5727은 인기 있는P-헤더들이 의도된 폐쇄 환경을 벗어났다고 나중에 기록했다. 일단 널리 배포되면, 접두사는 일반 이름으로의 그럴듯한 마이그레이션 경로를 제공하지 못했다. RFC 5727은 특수 절차를 폐기하면서도 파라미터 등록에 대해서는 작성자를 RFC 3968로 계속 안내했다.

RFC 6648은 이 교훈을 SIP 너머로 일반화했다. 구현은X-스타일 접두사의 유무만으로 표준화 여부나 보안을 추론해서는 안 된다. 철자는 수명 주기, 검토 상태, 신뢰를 담는 그릇으로 부적합하다. 내구성 있는 시스템은 이러한 속성을 명시적인 레지스트리 메타데이터와 참조에 담는다.

초기 RFC 3968 테이블은 출처가 왜 중요한지도 보여주었다. 다이제스트 관련 파라미터는RFC 3310에, 이벤트 파라미터는RFC 3265에, 사설 네트워크 필드는RFC 3455에, 보안 협의 파라미터는RFC 3329에 근거했다. 같은 테이블 형식이 서로 다른 메커니즘, 배포 전제, 보안 결과를 가진 항목들을 담았다. 행 형식은 발견을 통일했지, 동작을 통일하지 않았다.

현재 레지스트리는 살아있는 색인이다

IANA SIP 파라미터 레지스트리에는 이제 여러 개별 레지스트리가 담겨 있다. 헤더 필드, 메서드, 응답 코드, 옵션 태그, URI 파라미터, 헤더 필드 파라미터 등이다. 그 지속적인 성장은 안정적인 조정 표면의 가치를 보여준다. 그러나 목록에 있는 모든 메커니즘이 어디서나 구현되었다는 근거, 또는 특정 제품에서 전혀 구현되었다는 근거를 제공하지는 않는다.

유지 관리되는RFC Editor 기록,정오표 검색,IETF Datatracker는 공개 상태와 기록된 정정을 확립한다. 그러나 배포, 상호운용성 비율 또는 보안 결과를 측정하지는 않는다. 그 질문에는 다른 출처가 필요하다.

RFC 3968의 역사적 기여는 형식으로는 소박했지만 결과로는 컸다. 그것은 텍스트 확장 주장을 귀속 가능하게 만들었다. 이름은 찾을 수 있고, 범위가 정해지고, 그것을 정의한 문서까지 추적될 수 있었다. 규율은 거기서 멈추는 데 있다. 등록은 기록된 네임스페이스 결합을 증명한다. 엔드포인트는 여전히 자신이 무엇을 알고 무엇을 했는지 증명해야 한다.

출처