Resumo

  • Um perfil no RFC 10050 é um conjunto nomeado e versionado de restrições sobre propriedades, tipos e valores registrados do JSContact. Ele só pode tornar a especificação de base mais estrita.
  • O objeto Card não traz uma declaração universal de perfil. Como uma ficha pode pertencer a vários perfis, o protocolo externo precisa indicar qual nome e versão regem a troca e aplicar condições próprias.
  • O registro da IANA preserva a identidade histórica do perfil, mas não avalia obrigatoriamente seu conteúdo. Registro não equivale a aprovação de segurança, privacidade ou adequação operacional.

Imagine dois sistemas recebendo a mesma ficha. O primeiro informa: “JSContact válido e conforme ao perfil A, versão 2”. O segundo informa: “JSContact válido e conforme ao perfil B, versão 7”. Não há conflito se os dois subconjuntos se cruzam. O conflito só aparece quando alguém transforma uma dessas respostas em “mensagem autorizada” sem consultar o protocolo.

Publicado em setembro de 2026 como Proposed Standard, o RFC 10050 oferece uma maneira de nomear usos restritos de JSContact. A norma é cuidadosa para não vender esse nome como decisão completa de validade.

Restringir sem inventar outro formato

O Card do RFC 9553 atende a muitos cenários. Um serviço específico pode exigir uma propriedade opcional, proibir outra que o modelo geral aceita, reduzir os tipos permitidos ou limitar valores. O perfil formaliza essas escolhas.

Ele não pode flexibilizar a base. Um objeto inválido no JSContact continua inválido, mesmo que uma regra local pareça aceitá-lo. A sequência correta produz três resultados: validade do formato de base, conformidade com o perfil escolhido e validade no protocolo. Só o último responde se a mensagem deve prosseguir.

Nome sensível a maiúsculas e minúsculas mais uma versão inteira positiva formam a identidade do perfil. O conteúdo de um par registrado não pode ser alterado em silêncio. Uma revisão ganha número maior; versões antigas permanecem no registro.

Essa imutabilidade é o que torna um log durável. “Perfil X, versão 3” precisa apontar para as mesmas restrições depois que a versão 4 surgir. Sem isso, decisões armazenadas mudariam de significado e testes de interoperabilidade perderiam sua referência.

A conformidade desce pela árvore

Propriedades JSContact podem conter objetos. Um tipo permitido pode expor outras propriedades, que abrem novas estruturas. Por isso, o RFC 10050 trata o conjunto suportado de maneira recursiva, até alcançar o fechamento das propriedades acessíveis.

Uma lista simples de campos no nível superior não basta. Ela pode aceitar um ramo interno proibido. Um validador excessivamente literal pode fazer o oposto e rejeitar uma propriedade aninhada alcançável por um tipo autorizado. Os JSON Pointers do RFC 6901 localizam os elementos, mas não comprovam que toda a árvore foi percorrida.

O registro de validação deve guardar versão de base, nome e versão do perfil, versão do validador, caminhos examinados e regra responsável pelo resultado. Um selo verde isolado não revela a profundidade do teste.

Por que a ficha não se autodeclara

O RFC 10050 não cria uma propriedade geral dentro de Card para anunciar o perfil. Também não determina uma forma universal de transportar nome e versão. Essa tarefa pertence ao protocolo que utiliza a ficha.

Se o objeto aceita múltiplos perfis, um único rótulo seria incompleto. Uma lista ainda não revelaria qual deles foi negociado para a transação. Além disso, declaração do emissor não é prova do receptor. O protocolo já controla negociação, versões aceitas, tratamento de erros e restrições adicionais; deve controlar também a identidade aplicável.

Assim, um sistema auditável separa “JSContact válido”, “conforme ao perfil identificado” e “válido para este protocolo”. A ficha pode passar nas duas primeiras perguntas e falhar na terceira porque o protocolo proíbe algo que o perfil permite.

O limite do ato de registrar

Novas entradas usam a política Specification Required do RFC 8126. Mudanças de referência passam por Expert Review, e o IETF é o controlador de alterações. Os especialistas designados verificam unicidade e sintaxe, propriedades e tipos conhecidos, estabilidade do documento e avanço correto da versão.

O RFC deixa claro que eles não precisam julgar o conteúdo substantivo. Uma linha no registro não garante minimização de dados, segurança ou adequação a um setor. O RFC 9553 alerta para a sensibilidade de dados de contato; a organização que adota o perfil continua responsável por avaliar o que coleta e por quê.

Durante esta pesquisa, a página da IANA para JSContact mostrava a área de perfis sem entradas e os especialistas ainda não designados. A página registrava atualização em 28 de maio de 2026 e citava um Internet-Draft, estado anterior à publicação do RFC em setembro. É um retrato datado, não uma acusação de falha.

Mesmo assim, ele mostra por que o operador deve preservar sua própria cadeia de custódia: nome, versão, cópia ou hash da especificação, momento da consulta, versão base, software de validação, fechamento recursivo, modo de seleção no protocolo e regras extras. A atualização futura do registro não apaga o contexto antigo.

Fontes