RFC 9982: identificador de contato não é autoridade de identidade

O contato perdeu o UID. Não perdeu seus limites: RFC 9982 e a autoridade da identidade de registro

Por que isso importa

Um job de sincronização pode terminar sem erro, copiar todos os campos visíveis e ainda assim não ter recebido o direito de dizer que duas fichas são a mesma pessoa. Essa diferença aparece no centro da RFC 9982. Ao tornar `uid` opcional em JSContact 2.0 e proibir sua invenção quando a vCard de origem não possui `UID`, a especificação protege a utilidade da ficha sem transformar uma conveniência de conversão em autoridade para relacionar ou fundir dados.

Daniel Kade1 de setembro de 2026 às 03:09 UTCTempo de leitura 3 minÚltima atualização: 1 de setembro de 2026

Resumo

RFC 9982 permite que uma Card JSContact 2.0 não tenha uid e exige que a conversão de uma vCard sem UID não crie um uid para a versão 2.0.
Uma chave torna o registro apontável dentro de um modelo. Ela não demonstra, por si só, a identidade do contato, a vigência de uma relação, a procedência da afirmação ou a permissão para atualizar outra fonte.

O conflito que a RFC corrige nasceu de uma boa intenção técnica. Sistemas de sincronização precisam de identificadores estáveis para acompanhar objetos. Mas vCard sempre tratou UID como opcional, e outras representações podem não ter uso para uma chave desse tipo. Sob a regra anterior, converter uma vCard sem UID para JSContact exigia gerar uma sequência. O modo de geração era específico de implementação e não assegurava que duas conversões produziriam o mesmo resultado. Uma chave inventada para fechar uma lacuna de estrutura podia acabar servindo como membro de um grupo ou alvo de relatedTo.

JSContact 2.0 recusa essa promoção. A Card sem uid continua válida. Ela apenas não pode ocupar as posições do modelo que requerem referência estável: members e relatedTo. A ausência não significa que o contato é falso ou que os seus demais campos devem ser descartados. Significa que falta a evidência de modelo necessária para fazer uma ligação persistente entre registros.

Essa diferença separa sucesso técnico de autoridade. Uma transformação pode obedecer à sintaxe; uma sincronização pode gravar dados; uma chave local pode permanecer constante. Nada disso resolve automaticamente se duas fichas representam a mesma entidade, se alguém consentiu com a associação, se a fonte era competente para declarar o vínculo ou se o recebedor está autorizado a unir seus históricos. Mesmo um uid presente é uma string de Card: não é assinatura, prova de pessoa, credencial de conta, consentimento nem aprovação de merge.

O RFC também deixa claro que versão tem semântica operacional. Cards 1.0 válidas continuam válidas como 2.0; Card 2.0 sem uid não deve ser rejeitada por padrão. A conversão de uma fonte sem UID para v2 deve preservar essa ausência, enquanto a saída 1.0 carregava a antiga obrigação de gerar algo. Registrar JSCOMPS na IANA torna o vocabulário de conversão mais completo, não transforma a conversão em uma declaração verificada sobre relações humanas ou organizacionais.

CardDAV e JMAP Contacts podem demandar uma chave em seus próprios fluxos; RDAP pode não precisar dela. Essa diversidade não é uma falha a esconder com identidade sintética. Como sugere Heng Lu, a camada comum deve permitir intercâmbio sem tomar decisões que pertencem a contexto, procedência e governança local.