요약

  • RFC 10050은 JSContact 프로필을 등록된 속성, 타입, 값에 대한 이름과 버전이 지정된 제한 집합으로 정의합니다. 프로필은 JSContact을 좁힐 수는 있어도 기본 규칙을 완화할 수는 없으며, 하나의 카드가 여러 프로필을 동시에 충족할 수 있습니다.
  • 카드에는 보편적인 프로필 선언이 없습니다. 주변 프로토콜이 어떤 프로필이 적용되는지, 그 이름과 버전이 어떻게 전달되는지, 그리고 어떤 추가 유효성 규칙이 남아 있는지를 명시해야 합니다. 따라서 프로필 준수는 증거이지 수용 증명서가 아닙니다.
  • 레지스트리 식별은 내구성이 있습니다. 프로필 이름과 버전은 불변 콘텐츠를 식별하고, 이전 버전은 계속 표시되며, 이후 등록에는 새 버전이 부여됩니다. 그러나 지정 전문가(Designated Experts)는 레지스트리 형식과 참조 적합성을 검토할 뿐, 프로필의 실질적 설계를 인증하지는 않습니다.

두 개의 독립적인 검증기를 통과하는 연락처 카드를 생각해 봅시다. 하나는 디렉터리 교환에서 사용하는 프로필의 준수를 보고합니다. 다른 하나는 주소록 동기화 서비스에서 사용하는 더 좁은 프로필의 준수를 보고합니다. 둘 다 맞을 수 있습니다. 같은 카드가 허용된 두 부분 집합의 교집합에 존재할 수 있기 때문입니다.

이제 운영상의 질문을 던져 봅시다. 그 카드를 담은 특정 프로토콜 메시지를 수용할 수 있는가?

검증기들은 이 질문에 답하지 않았습니다. 메시지는 잘못된 프로필 버전을 주장했을 수 있습니다. 그 프로토콜은 프로필이 허용하는 속성을 금지했을 수 있습니다. 수신자는 선언된 적 없는 프로필을 요구하거나, 카드 외부에서 식별이 전달되는 협상된 프로필을 적용했을 수 있습니다. 카드의 JSON은 유효한 JSContact이고 등록된 프로필에 준수하면서도 프로토콜 교환 자체는 여전히 유효하지 않을 수 있습니다.

이 구분이RFC 10050, 즉 JSContact 프로필에 관한 2026년 9월 제안 표준(Proposed Standard)의 핵심입니다. 이는 또 하나의 연락처 데이터 형식이 아닙니다. 이름을 완전한 프로토콜 계약으로 착각하지 않고 형식의 제한된 사용에 이름을 붙이는 방식입니다.

내구적 식별을 지닌 하위 집합

RFC 9553은 JSContact 데이터 모델과 그Card객체를 정의합니다. RFC 10050은 일반 모델은 특정 응용이 원하는 것보다 보통 더 많은 변형을 허용한다는 관찰에서 출발합니다. 프로필은 선택적 속성을 필수로 만들고, 다른 방식으로는 유효한 속성을 금지하며, 허용된 타입을 제한하거나 더 좁은 값을 선택할 수 있습니다. 프로필은 기본 사양만 조일 수 있습니다. 유효하지 않은 JSContact을 유효한 JSContact으로 바꿀 수는 없습니다.

프로필은 IANA JSContact Profiles 레지스트리에서 대소문자를 구분하는 이름과 양의 정수 버전으로 식별됩니다. 이 두 필드를 함께 안정적 키로 작동합니다. 일단 등록되면 이름-버전 쌍에 연관된 콘텐츠는 그 자리에서 수정되지 않습니다. 변경된 프로필은 더 큰 버전을 받고 이전 버전은 레지스트리에 남습니다.

이 불변성은 보관상의 정돈 이상의 의미가 있습니다. 어떤 구현이example버전 2를 검증했다고 주장하면, 운영자는 버전 3이 등장한 뒤에도 그 진술이 같은 의미를 유지하기를 기대합니다. 버전 2 뒤의 참조를 조용히 교체하면 로그, 적합성 보고서, 저장된 메시지가 제공하던 증거가 녹아 없어집니다. 따라서 레지스트리 이력은 프로토콜 기억의 일부입니다.

준수에는 재귀적 가장자리가 있다

프로필에 대한 직관적인 독해는 최상위 속성 목록입니다. 그러나 RFC 10050은 더 세심함을 요구합니다. 한 속성은 중첩된 객체를 담을 수 있고, 한 속성에 허용된 타입은 그 아래 더 많은 속성을 도입할 수 있습니다. 따라서 지원되는 속성 집합은 재귀적입니다. 검증기는 허용된 속성/타입 그래프를 폐쇄 지점까지 따라가야 합니다.

시스템이 프로필을 얕은 허용 목록으로 구현할 때 이것이 중요해집니다. 최상위 속성은 허용되면서 그 안의 중첩 속성이나 타입은 프로필 밖일 수 있습니다. 반대로, 최상위 규칙 옆에 인쇄되지 않은 모든 중첩 필드를 거부하면 허용된 타입을 통해 도달 가능한 필드까지 제외할 수 있습니다.RFC 6901JSON 포인터가 프로필 요소를 정확히 식별하는 데 쓰이지만, 올바른 포인터가 모델 순회를 대신하지는 않습니다.

결과는 작지만 중요한 구현상 진실입니다. 프로필 준수는 도장으로 찍히는 것이 아니라 계산되는 것입니다. 검증기에는 기본 JSContact 규칙, 정확한 등록 프로필 버전, 그리고 그 버전이 허용하는 속성 구조에 대한 재귀적 설명이 필요합니다.

카드 내부에 프로필 라벨이 없다

RFC 10050은 프로필 소속을 알리는 속성을Card에 추가하지 않기로 의도적으로 결정했습니다. 프로필 이름이나 버전을 담는 보편적 방식 하나를 정의하지도 않습니다. 그 메커니즘은 임베딩 프로토콜이 소유합니다.

이는 오도적인 자기 주장을 피합니다. 하나의 카드가 여러 프로필을 충족할 수 있으므로, 객체 내 단일 라벨은 유효한 정보를 버리거나 맥락에 따라 관련성이 달라지는 주장의 배열을 초대하게 됩니다. 더 근본적으로, 발신자의 주장은 수신자의 검증이 아닙니다. 프로토콜은 이미 협상, 요구 버전, 오류 동작, 프로필을 넘는 규칙을 정의해야 하며, 적용되는 프로필이 선택되고 전달되는 방식도 정의해야 합니다.

따라서 관리(custody) 사슬에는 구분된 기록들이 있습니다. 메시지에는 프로토콜이 어떤 프로필을 기대했는지에 대한 증거가 필요하고, 검증기에는 평가한 불변 이름-버전 정의가 필요하며, 수신자에는 기본 JSContact 검증, 프로필 검증, 프로토콜 고유 검사의 결과가 필요합니다. 이것들을valid라는 하나의 불리언으로 합치면 RFC가 지키려는 바로 그 경계가 사라집니다.

레지스트리는 설계를 승인하지 않는다

새 JSContact 프로필 등록은RFC 8126이 설명하는 Specification Required 정책을 따릅니다. 참조 업데이트는 전문가 검토(Expert Review) 대상이며 IETF가 변경 관리자(change controller)입니다. RFC 10050은 지정 전문가들에게 실용적 레지스트리 사항을 점검하도록 요구합니다. 식별자가 고유하고 통상적으로 건전한지, 참조된 속성과 타입이 알려져 있는지, 사양이 평가 가능할 만큼 안정적인지, 새 버전이 버전 번호를 올리는지입니다.

또한 한계를 그립니다. 전문가들은 프로필의 실제 내용을 평가할 필요가 없습니다. 등록은 선택된 하위 집합이 안전하거나, 완전하거나, 특정 배포에 적합하다는 인증이 아닙니다. 레지스트리 항목은 안정적인 식별 아래 내구적 사양을 찾을 수 있다고만 말합니다. 그것에 붙이는 정책의 책임은 여전히 프로토콜 소유자에게 있습니다.

이 단서는 주목할 가치가 있습니다. 레지스트리는 종종 형식적 역할을 넘어 사회적 권위를 얻기 때문입니다. 등록된 프로필은 두 구현이 같은 정의를 검색한다는 좁은 의미에서 상호운용적일 수 있으면서도, 불량한 프라이버시 선택을 하거나 특정 분야에 필수적인 필드를 생략할 수 있습니다.RFC 9553은 연락처 데이터가 민감할 수 있고 데이터 최소화가 중요하다고 경고합니다. 프로필의 제한은 최소화에 도움이 될 수 있지만, 레지스트리 한 줄이 리스크 평가를 수행하지는 않습니다.

비어 있는 제어 표면에 대한 시점이 기록된 시각

이 검토 시점에IANA JSContact 레지스트리 페이지는 JSContact Profiles 섹션에 등록이 하나도 없고 지정 전문가도 아직 배정되지 않은 채로 표시되고 있었습니다. 페이지에는 2026년 5월 28일의 최종 업데이트 날짜가 나타나고 여전히 Internet-Draft 참조를 인용하고 있었습니다. RFC 10050은 그보다 늦은 2026년 9월에 출판되었습니다.

이는 방치의 증거가 아니라 시점이 기록된 스냅샷입니다. 출판과 레지스트리 업데이트는 서로 다른 일정으로 진행될 수 있습니다. 그럼에도 이는 배포가 사용하는 레지스트리 상태를 캡처해 두어야 할 운영상의 이유입니다. 현재 페이지, RFC, 로컬 소프트웨어가 모두 같은 순간을 묘사한다고 가정해서는 안 됩니다.

프로필 지원을 주장하는 구현은 관리 기록을 생성할 수 있어야 합니다. 프로필 이름과 버전, 참조된 사양의 다이제스트나 보관본, 검색 시각, 기본 JSContact 버전, 검증기 버전, 재귀적 속성 집합 결과, 프로토콜이 전달한 프로필 선택, 적용된 모든 추가 프로토콜 규칙이 그것입니다. 레지스트리가 나중에 바뀌더라도 과거의 결정은 재구성 가능해야 합니다.

출처