Resumo

  • RFC 9553 seleciona um PatchObject por etiqueta de idioma, copia o Card sem localizations, aplica o conjunto inteiro e usa a cópia como variante localizada.
  • A rejeição integral impede resultado parcial, mas não autentica o redator, aprova um nome alternativo, confirma vigência nem concede poder para alterar os dados.
  • Uma trilha confiável liga impressão digital do Card base, política de idioma, patch exato, autorização, saída e uso posterior.

A interface mostra um objeto; o protocolo preserva uma derivação

O leitor recebe uma ficha completa. Não vê quais palavras vieram do original nem quais foram substituídas. Essa completude visual sugere uma origem independente para cada idioma.

Em RFC 9553, localizations é um mapa: etiquetas RFC 5646 apontam para PatchObjects. A aplicação determina a etiqueta, obtém o patch correspondente, cria uma cópia do Card sem copiar localizations, aplica as alterações, pode ajustar language e apresenta o resultado como variante do Card original.

Não surge outro uid. Não surge um histórico de revisão separado. Os campos não alterados continuam herdados da base, enquanto os alterados dependem do patch e da regra de seleção.

Persistir somente a saída destrói essa explicação. Quando o cargo divergir, ninguém saberá se a base estava antiga, se o patch era velho, se houve fallback ou se um cache sobreviveu. A projeção reproduzível vira uma duplicata soberana sem linhagem.

Tudo ou nada não significa verdadeiro ou falso

PatchObject usa caminhos de um subconjunto de JSON Pointer, com barra inicial implícita. Os segmentos anteriores ao último precisam existir. Pode-se substituir elemento existente de array, mas não usar para inserir ou excluir. Dois caminhos não podem ter relação de prefixo. O valor precisa obedecer ao tipo e às regras da propriedade; null remove apenas propriedade opcional.

Se uma operação for inválida, o objeto todo deve ser rejeitado. Aplicação parcial é proibida. Isso impede que um nome mude enquanto a parte inválida de um endereço seja esquecida.

O sucesso, porém, é estreito. Ele afirma que a transformação é estruturalmente válida contra aquela base. Não afirma que a tradução é boa, que o cargo continua atual, que o nome é oficial ou que o autor podia trocar o telefone.

Um painel responsável separa: JSON analisado, modelo válido, patch aplicável, origem autenticada, campo autorizado, nome aprovado, dado atual e contato observado. Um único selo “localizado” não pode absorver essas decisões.

O caminho envelhece com a base

O RFC mostra a troca completa de name e uma alteração interna em titles/t1/name. A segunda preserva os demais membros de t1; funciona porque a estrutura e a chave continuam estáveis.

Chaves Id em mapas devem ser preservadas entre versões do mesmo objeto JSContact. Isso facilita patches pequenos. Ainda assim, o mesmo Id em mapas ou Cards diferentes não implica ligação semântica. t1 é coordenada local, não identidade mundial.

Um patch aprovado sobre a impressão A pode continuar analisável sobre B mesmo quando t1 passou a representar outro cargo. Pode falhar se a chave sumiu. Pode permanecer correto quando só um campo irrelevante mudou. O validador distingue a falha estrutural, não decide sozinho os outros casos.

updated indica quando os dados do Card foram modificados, não quais campos, por quem, com qual fonte ou se as localizações foram revisadas. prodId identifica o produto, não um signatário. version é a versão do modelo JSContact, não a geração editorial daquela ficha.

Por isso, patch e base precisam de impressões digitais vinculadas. A revisão de negócio e o intervalo efetivo completam a decisão sobre reutilização.

Escolher idioma também é escolher política

Etiquetas RFC 5646 expressam idioma, escrita e região. RFC 9553 começa por “determinar” a etiqueta. A política completa fica fora do formato: preferência do usuário, correspondência exata, fallback regional, prioridade de escrita e retorno ao conteúdo principal.

Uma etiqueta correta não certifica a string. Um nome de organização pode ser oficial, tradução conhecida, transliteração, conveniência editorial ou invenção. O nome de uma pessoa em outra escrita pode ser uma forma original comprovada ou apenas uma aproximação automática.

O PatchObject carrega a alternativa; não a transforma em alias oficial. Mudanças em nomes protegidos devem apontar para fonte institucional, confirmação do sujeito ou regra de transliteração revisada. Sem isso, o sistema possui uma apresentação possível, não uma nova identidade.

O mesmo vale para endereços e cargos. Reordenar componentes pode ser legítimo; trocar uma jurisdição ou elevar o sentido do cargo não é detalhe de exibição. A validação de tipo não percebe essa diferença.

A fraude pode falar a língua do leitor

As considerações de segurança dizem que dados de contato expõem identidade, localização, credenciais, emprego, interesses e relações. Citam escuta, replay, inserção, remoção, alteração e ataques no caminho.

O exemplo mais relevante é a personificação: o atacante usa o nome de outra pessoa e insere seus próprios contatos. Uma versão fluente aumenta a credibilidade da fraude. Título natural, escrita familiar e endereço bem formatado desviam atenção de quem controla email e telefone.

Sistemas com consequências reais devem autenticar os dados e garantir que a mudança veio de entidade autorizada. O próprio RFC limita seu alcance: define o formato, não a API, o armazenamento ou o transporte.

TLS pode provar qual serviço entregou o Card sem provar que o serviço tinha poder sobre todos os campos. Assinatura pode atribuir o patch sem demonstrar consentimento do titular. Schema pode rejeitar ponteiro inválido sem reconhecer uma mentira bem tipada.

Registro válido não é contato verificado

RFC 9553 registra JSContact 1.0 e cria registros IANA de versões, propriedades, tipos e valores enumerados. Since Version e Until Version permitem coordenar a evolução do vocabulário.

Essa autoridade é de interoperabilidade. O registro confirma que uma propriedade existe em um modelo; não que o valor de uma instância é verdadeiro. “JSContact válido” deve significar validade sob versão e snapshot declarados, não “pessoa verificada”.

Confundir os dois transforma governança de formato em governança de identidade. A interface deve deixar explícito qual veredito foi realmente produzido.

Uma trilha curta basta

O recibo mínimo contém uid, versão do modelo, hash e revisão da base; solicitação ou regra que escolheu a etiqueta; PatchObject exato, origem, assinatura e escopo; resultado integral; hash da saída; horário e consumidor.

Se houver nome de pessoa ou instituição, agrega-se a evidência do alias. Se telefone, email, endereço ou cargo mover uma automação, registra-se a ação e seu resultado. Renderização não prova entrega nem sucesso.

Quando a base mudar, a trilha permite classificar cada patch como não afetado, sujeito a revisão ou inválido. Não é necessário criar nove bancos de fatos e esperar que conversem.

Localização melhora acesso quando continua sendo uma transformação explicável. A confiança cai quando a apresentação apaga a cadeia que liga texto, fato, poder e efeito.

Fontes