Кратко

  • Профиль RFC 10050 — именованный и версионируемый набор ограничений для зарегистрированных свойств, типов и значений JSContact. Он может только сузить базовые правила.
  • В объекте Card нет универсального объявления профиля. Карточка может соответствовать нескольким профилям, поэтому внешний протокол задаёт применимые имя и версию, способ их передачи и дополнительные условия.
  • Реестр IANA сохраняет историческую идентичность пары имя–версия, но регистрация не подтверждает качество, безопасность или пригодность содержания профиля.

В системе может существовать безупречный результат проверки, который не отвечает на нужный вопрос. Валидатор подтвердил JSContact. Второй валидатор подтвердил профиль. Но оператору нужно решить, допустимо ли сообщение в конкретном протоколе. Между этими выводами нет знака равенства.

RFC 10050, опубликованный в сентябре 2026 года как Proposed Standard, формализует это разделение. Он не создаёт новый формат контактных данных, а даёт устойчивую идентичность ограниченным способам применения общей модели.

Одностороннее ограничение

Модель Card из RFC 9553 рассчитана на разные сценарии. Профиль может сделать необязательное свойство обязательным, запретить допустимое в базе свойство, сократить набор типов или значений. Ослабить базовую спецификацию он не вправе.

Поэтому проверка состоит из трёх ступеней: базовая валидность JSContact, соответствие выбранному профилю и валидность для использующего протокола. Последняя ступень может содержать ограничения, которых в профиле нет.

Идентификатор профиля складывается из чувствительного к регистру имени и положительной целочисленной версии. Содержимое зарегистрированной пары не заменяется. Изменение получает больший номер, прежние версии сохраняются.

Такой порядок удерживает смысл исторических доказательств. Если журнал указывает версию 2, после появления версии 3 он по-прежнему должен ссылаться на тот же набор ограничений. Иначе старое решение менялось бы вместе с текущим состоянием реестра.

Рекурсивный набор свойств

JSContact имеет вложенную структуру. Свойство может содержать объект, разрешённый тип — открывать новые свойства, а те — следующие уровни. RFC 10050 требует вычислять поддерживаемое множество рекурсивно, до замыкания достижимых свойств.

Плоский белый список верхнего уровня способен пропустить запрещённую ветвь. Слишком буквальный валидатор, напротив, отклонит вложенное свойство, законно достижимое через разрешённый тип. JSON Pointer из RFC 6901 точно указывает место, но не доказывает полноту обхода.

Надёжная запись проверки должна содержать базовую версию, имя и версию профиля, версию валидатора, пройденные связи свойств и типов, а также конкретное сработавшее правило. Один логический флаг скрывает объём проверки.

Почему карточка не объявляет профиль сама

RFC 10050 не добавляет в Card общего поля профиля и не предписывает один контейнер для имени и версии. Это определяет протокол, в который встроена карточка.

Карточка может находиться на пересечении нескольких профилей. Единственная внутренняя метка потеряет информацию; список меток всё равно не покажет, какой профиль согласован для обмена. Кроме того, утверждение отправителя не является проверкой получателя. Протокол уже определяет согласование, допустимые версии, ошибки и дополнительные запреты — он же должен переносить применимую идентичность.

Практическая система хранит отдельно три факта: базовая валидность, соответствие точному профилю и решение протокола. Профиль может разрешать свойство, которое протокол запрещает, и тогда второе значение будет положительным, а третье — отрицательным.

Реестр — не сертификат содержания

Новые записи используют политику Specification Required из RFC 8126, изменение ссылки требует Expert Review, контролёром изменений выступает IETF. Назначенные эксперты проверяют уникальность и синтаксис имени, известность свойств и типов, стабильность спецификации и увеличение номера версии.

RFC 10050 не требует от них оценки содержания профиля. Запись не удостоверяет безопасность, приватность или отраслевую применимость. RFC 9553 предупреждает о чувствительности контактных данных, однако решение о минимизации остаётся у внедряющей организации.

Во время исследования страница IANA для JSContact показывала раздел Profiles без записей и без назначенных экспертов. Датой последнего обновления значилось 28 мая 2026 года, а ссылка ещё вела на Internet-Draft — состояние до сентябрьской публикации RFC. Это датированный снимок, а не обвинение: циклы обновления могут различаться.

Тем важнее собственная запись происхождения решения: имя и версия, копия или хеш спецификации, время получения, базовая версия JSContact, версия валидатора, результат рекурсивного замыкания, способ передачи выбора профилем и дополнительные правила. Тогда изменение страницы не разрушит контекст прошлого.

Источники