요약

  • RFC 3349는 IETF 워킹 그룹 의장이 채널 협상 중 구현체가 사용할 수 있는 임시 BEEP 프로파일 URI를 승인할 수 있도록 했다.
  • 그 작업용 식별자는 이후의 영구 IANA 등록도, RFC 출판 접수도, 보안 검토도, 어떤 구현이 실제 배포되었다는 증거도 아니었다.

BEEP에서 프로파일 이름은 장식적인 메타데이터가 아니었다. RFC 3080은 채널을 지배하는 규칙을 식별하기 위해 URI를 사용했다. 한 피어가 채널 열기를 요청할 때 하나 이상의 프로파일 URI를 제시하면, 상대 피어는 자신이 사용할 의향이 있는 것을 선택하거나 요청을 거부했다. 따라서 양측이 합의한 문자열은 새 채널에서 어떤 메시지가 적법한지를 바꿀 수 있었다. 이름은 이미 실질적인 운영 역할을 하고 있었다.

이는 워킹 그룹에게 실질적인 문제를 만들었다. 구현자는 사양이 완성되기 전에 하나의 공유 식별자가 필요한 경우가 많다. 그것이 없으면 두 프로토타입이 같은 초안을 서로 다른 이름으로 구현하거나, 서로 무관한 초안들이 하나의 편리한 이름에 충돌할 수 있다. 최종 출판을 기다리면 초안을 개선하는 데 필요한 증거가 더 이상 초안에 반영될 수 없을 때까지 상호운용성 작업이 지연된다. 반대로 최종 이름을 너무 일찍 할당하면 프로세스가 그 정당성을 아직 얻기도 전에 임시 설계가 영구적인 것처럼 보이는 오류가 생긴다.

RFC 3349는 명백히 임시적임을 드러내는 이름공간으로 이 좁은 문제를 해결했다. IETF 사무국(Secretariat)이 워킹 그룹을 구성할 때 그룹에게 짧은 니모닉을 할당했다. 그 그룹이 BEEP 프로파일 정의를 시작하면, 의장은http://iana.org/beep/transient/XXX/YYY아래의 URI를 선택할 수 있었다. 그룹 니모닉이XXX를 채우고, 프로파일을 위해 선정된 고유 문자열이YYY를 채웠다. 의장은 그런 뒤 BEEP가 정의한 등록 템플릿을 작성해 IANA로 보냈다.

이 절차는 권한을 신중하게 분산했다. 사무국은 그룹 니모닉을 통제했다. 의장은 그 그룹 내부의 작업에 대해 임시 등록을 승인했다. IANA는 할당을 기록했다. 이 어느 단계도 IESG가 표준 트랙 RFC를 승인했다는 의미가 아니었다. RFC 3349의 부록은 이 차이를 강조했다. 의장이 임시 항목을 승인하는 반면, RFC 3080이 기술한 영구 표준 트랙 절차는 IESG의 승인을 사용한다.

URI 내부의 도메인 이름이 이 구분을 특별히 중요하게 만들었다. 독자는iana.org를 보고 IANA가 그 기술 설계를 보증했다고 추정할 수 있다. 이 메모는 그러한 추론을 지지하지 않았다. IANA의 역할은 명시된 정책 아래의 레지스트리 행정이었다. 관련 개발 시점의 승인은 의장이 제공했다. 워킹 그룹은 여전히 문서를 개정하고 합의를 형성하며 이후 적용되는 검토를 통과해야 했다. 레지스트리의 한 행은 식별자를 기록할 뿐, 프로파일을 작성하거나 코드를 시험하거나 결과를 인증하지 않았다.

http라는 표기도 이 식별자를 배포 점검 도구로 바꾸지 않았다. 이 URI는 BEEP 협상에서 신원 토큰으로 기능했다. 피어들은 채널을 생성할 때 그 값을 비교했다. 그 비교에 브라우저가 페이지를 성공적으로 가져와야 한다는 요구는 없었고, 성공적인 검색이 그 피어가 해당 프로파일을 구현했다는 증거가 될 수도 없었다. URI 구문, 레지스트리 상태, 프로토콜 지원, 네트워크 도달성은 서로 별개의 관찰이었다.

RFC 3349는 예시용 임시 이름 두 개를 제시했는데, 하나는 EPP 작업에, 다른 하나는 SACRED에 관련된 것이었다. 이들은 이름공간 형태의 유용한 예시일 뿐, 배포 증거가 아니다. 이후의 SACRED 자격 증명 서버 RFC는 영구 프로파일 URIhttp://iana.org/beep/sacred를 사용했으며, 예시적인/transient/sacred/pdm형식을 유지하지 않았다. 이 비교는 소프트웨어가 개발용 이름에서 영구 이름을 안전하게 추측할 수 없는 이유를 보여준다. 자료들은 어떤 프로토타입이 어떻게 이전되었는지, 두 이름이 함께 수용된 적이 있는지, 예시용 임시 문자열이 실제 등록되었는지조차 확인해 주지 않는다.

APEX는 거의 동시대의 영구적인 대조 사례를 제공한다. RFC 3340은http://iana.org/beep/APEX를 정의하고 IANA가 이를 표준 트랙 BEEP 프로파일로 등록했다고 기술했다. 같은 URI가 현재 IANA BEEP 매개변수 레지스트리에도 나타난다. 그러나 그 영구 등록 행조차 문서화된 등록 상태만을 증명할 뿐이다. 이는 특정 바이너리가 APEX를 올바르게 구현했는지, 두 버전이 상호운용했는지, 어떤 서비스가 도달 가능했는지, 응용 결과가 발생했는지를 증명하지 않는다.

현재 IANA 레지스트리는 APEX와 SACRED 같은 표준 트랙 BEEP 프로파일을 보여준다. 이 기사를 위해 캡처한 공개 HTML과 XML에는 별도의 임시 레지스트리 섹션이 노출되지 않는다. 이는 한정된 현재 시점의 관찰이다. 임시 목록이 언제 바뀌었는지, 이전 항목들이 다른 곳에 보관되었는지, 공개 표면이 왜 지금 이 모양인지는 알려주지 않는다. 현재 표에서의 부재는 다른 기록 없이는 역사적 삭제 서사로 승격되어서는 안 된다.

가장 내구적인 설계 선택은 문자 그대로의 접두어가 아니었다. 그것은 수명 주기 공개였다.transient라는 단어가 이름과 함께 다니면서 구현자와 운영자가 이 식별자가 개발에 속한 것임을 알 수 있게 했다. 이는 임시 권한에게 영구 권한을 사칭하도록 요구하지 않으면서 실험을 더 쉽게 만들었다. 이 메커니즘은 프로토콜 자료 속에 박힌 작은 제도적 정직성이었다.

동시에 이전(migration) 의무도 남겼다. 프로토타입들이 임시 URI를 주고받은 뒤에는 설정 파일, 테스트 스위트, 캡처, 코드가 그 값 주위에 축적될 수 있다. 영구 프로파일의 출판이 그러한 산물들을 자동으로 다시 쓰지는 않는다. 한 피어가 영구 URI로 전환하는 동안 다른 피어가 임시 값을 유지하면, 양측이 유사한 메시지 의미론을 구현하고 있더라도 채널 협상이 실패할 수 있다. 소프트웨어가 양쪽을 무기한 수용하면 임시 이름이 우연한 호환성 표면이 될 수 있다. RFC 3349는 준비 단계 이름공간을 제공했을 뿐, 보편적인 별칭·리다이렉트·폐기 절차를 정의하지 않았다.

메모의 보안 섹션 역시 한정적이었다. 이 행정적 관행이 새로운 보안 고려사항을 추가하지 않으며, BEEP 기반 프로토콜 각각은 자체적인 분석이 필요하다고 명시했다. 따라서 임시 등록은 피어를 신뢰하거나, 어떤 행위를 승인하거나, 프로파일별 통제를 완화할 권한을 부여하지 않았다. 이름에 대한 합의는 하나의 접수 증명에 불과했다. 양 피어가 한 채널에 대해 동일한 선언된 프로파일을 선택했다는 뜻이다. 인증, 권한 부여, 메시지 유효성, 응용 처리, 유의미한 결과에는 다른 증명들이 필요했다.

이것이 크기는 작지만 RFC 3349가 인터넷 역사에서 자리를 차지하는 이유다. 표준화 작업은 최종 표준을 갖기 전에 식별자를 필요로 한다. 인터넷의 대답은 그 지저분한 구간을 부정하거나 완성과 혼동하는 것이 아니었다. 제한된 이름, 제한된 승인자, 보이는 경고를 할당했다. URI는 작동할 수 있었다. 프로파일은 여전히 바뀔 수 있었다. 영구성은 항상 이후의 결정이었다.

출처