Resumo

  • draft-ietf-calext-vcard4-bis-00 usa UID, PID e CLIENTPIDMAP para tornar parte da sincronização determinística, mas não define um desfecho universal para mapas de origem inconsistentes.
  • Onde a especificação termina, começa a autoridade do operador: preservar entradas, registrar a política, manter reversibilidade e não apresentar uma escolha local como imposição do formato.

Um conflito pequeno pode mudar a genealogia inteira

O segundo campo de um PID contém um número de fonte pequeno, válido apenas dentro daquela instância de vCard. CLIENTPIDMAP associa esse número a uma URI e lhe dá contexto global. É assim que dois dispositivos podem decidir se propriedades com números locais semelhantes pertencem à mesma linhagem.

Agora imagine que duas cópias da mesma ficha chegam com o mesmo número de fonte apontando para URIs diferentes. Uma pode ter renumerado o contexto de maneira legítima. A outra pode estar desatualizada. Também pode haver corrupção, colisão ou substituição maliciosa.

A revisão 00 diz que o motor deve manter os mapas consistentes, mas que, se não estiverem, o resultado fica a cargo do motor e é indefinido pelo documento. A especificação não finge conhecer o histórico, o repositório de confiança ou a política de cada implantação.

Essa honestidade cria uma obrigação operacional. O motor não recebeu licença para apagar uma das versões sem vestígio. Recebeu uma fronteira: dali em diante, qualquer ação é local e precisa de justificativa local.

O documento ainda é um Internet-Draft

A revisão 00 de vCard Format Specification é de 2 de julho de 2026 e expira em 3 de janeiro de 2027. É um documento do grupo CALENDAR EXTENSIONS, destinado ao Standards Track, que substituiria a RFC 6350 se aprovado. Não é ainda uma RFC, nem prova de implementação, interoperabilidade entre produtos ou resultado de produção.

O formato tem valor concreto. Ele permite que sistemas independentes troquem nomes, endereços, telefones, organizações, fotografias, chaves, calendários e relações. A sintaxe comum e os registros da IANA reduzem ambiguidades e extensões privadas.

O valor se perde quando se atribui ao formato poder sobre fatos que ele apenas representa. Uma vCard bem formada não autentica a pessoa. Uma URI de origem não assina o campo. Uma sincronização concluída não confirma que o telefone funciona.

Running-Code Primacy, em docs/heng-lu-note.md, separa documento, implementação, validação, uso e resultado. Minimum Initial Specification recomenda uma base comum estreita, deixando decisões futuras e contextuais com quem as executa. A sincronização de vCard ilustra esse desenho: invariantes compartilhados no centro, julgamento local nas bordas.

UID cria o conjunto de reconciliação

O texto define sincronização como a fusão inteligente de duas representações do mesmo objeto. Fichas com UID equivalentes devem ser combinadas no mesmo processo.

Se ambos os valores são URIs válidas, aplica-se a equivalência da RFC 3986. Caso contrário, compara-se o conteúdo caractere por caractere depois de remover o escape de texto. Essa regra evita que uma ficha compartilhada volte como um contato totalmente novo após edições independentes.

Mas UID tem cardinalidade *1, não 1. Pode faltar. Quando UID não resolve o caso, o motor pode considerar duas fichas equivalentes por discrição. Mesmo quando resolve, o identificador não verifica a pessoa real, não comprova o mandato do emissor e não autoriza automaticamente a fusão de cada campo.

UID tem autoridade para abrir uma reconciliação. Não tem autoridade para encerrar uma investigação de identidade.

PID dá nome a uma propriedade, não direito sobre ela

Depois de combinar as fichas, o motor precisa reconhecer as propriedades. O primeiro campo de PID é o identificador local do valor. O segundo é a fonte local. CLIENTPIDMAP liga essa fonte a uma URI.

Cada número de fonte usado precisa de um mapa, e zero não é permitido. Quando os primeiros campos coincidem e as URIs das fontes são equivalentes, os PID podem representar o mesmo valor global.

O mecanismo preserva escopos. O número 1 em dois aparelhos não se torna global por acidente. A URI do mapa fornece a distinção.

Ainda assim, não existe assinatura nessa associação. O fato de uma entrada nomear um UUID não comprova que o dispositivo correspondente criou o valor, que o mapa chegou intacto ou que a fonte podia substituir outra. O formato fornece comparabilidade; autenticação e autorização precisam vir de fora.

Regras obrigatórias limitam a heurística

Propriedades de fichas não combinadas não podem ser combinadas. Propriedades com nomes diferentes também não. Dentro de fichas já correspondentes, propriedades de mesmo nome e cardinalidade máxima um devem corresponder. Propriedades de mesmo nome com PID equivalentes também devem.

Essas regras impedem que semelhança de texto governe tudo. Um TEL não vira EMAIL, um valor de outra pessoa não migra para o contato atual, e uma identidade de propriedade conhecida não pode ser ignorada por conveniência.

Nos demais casos, o motor pode combinar propriedades de mesmo nome por discrição. É o espaço de números normalizados, grafias alternativas, endereços parecidos e intenção humana.

O MAY não desloca a responsabilidade para o IETF. A implantação deve registrar dados de entrada, normalização, versão da regra, confiança, limiar e decisão. A especificação permite o julgamento; não o executa.

O exemplo inteligente une telefones, mas não e-mails

No exemplo de edição simultânea, dois dispositivos adicionam, cada um, um e-mail e um telefone. Os novos valores têm PID globais diferentes porque vieram de contextos distintos.

Os e-mails permanecem separados. Ambos são copiados. Os telefones também têm PID distintos, mas exibem a mesma sequência. Um motor descrito como particularmente inteligente decide que representam uma única propriedade e os funde.

O resultado pode ser exato. Pode também ignorar uma extensão, um uso profissional, uma diferença de confiança ou uma obrigação de conservar as fontes separadas. A ficha final mantém os dois PID no TEL unificado, mostrando que duas linhagens convergiram. Ela não registra por que convergiram.

Um recibo adequado guarda hashes dos valores originais, PID, mapas, forma normalizada, regra ou modelo, confiança, política, ator e instante. Uma confirmação humana deve aparecer como evento separado da sugestão automática.

Sem esse recibo, o estado final só prova o que foi armazenado.

Inconsistência deve reduzir, não aumentar, a certeza

Um conflito de CLIENTPIDMAP é um ponto em que a automação deveria ficar mais cautelosa. Se a genealogia das fontes está em disputa, apagar um lado torna a decisão mais difícil de revisar.

Há várias estratégias legítimas: quarentena, preservação de ambos os contextos, consulta a um histórico assinado ou solicitação ao usuário. A escolha depende do risco. Uma agenda pessoal pode tolerar uma pergunta. Um diretório corporativo ou contato de emergência pode exigir dupla aprovação.

O mínimo comum é não destruir as entradas antes de criar um recibo. O sistema deve registrar o tipo de inconsistência, a política aplicada, a transformação resultante e o hash de saída.

Se a interface mostrar apenas “sincronizado com sucesso”, ela terá convertido incerteza estrutural em falsa certeza operacional.

A simplificação troca contexto por eficiência

Depois da fusão, o exemplo reduz o contexto global. Como só há dois dispositivos, renumera propriedades, elimina uma entrada de CLIENTPIDMAP e produz uma ficha menor.

O documento afirma expressamente que os detalhes dessa simplificação não são especificados. É uma possibilidade ilustrativa, não um algoritmo completo.

Compactar é necessário em muitos sistemas distribuídos. Um estado materializado serve consultas melhor que um histórico infinito. O erro é destruir o histórico e depois chamar o estado de histórico.

A implantação pode servir a vCard curta e manter um registro append-only separado com hashes de entrada, mapas antigos, correspondência de numeração, conflitos, decisões e hash final. Assim, o objeto portátil continua simples e a auditoria continua possível.

O estado responde “o que acreditamos agora”. O recibo responde “como chegamos aqui”.

Transporte autenticado não autoriza a fusão

vCard não tem autenticação ou confidencialidade inerentes. A revisão menciona proteção por mecanismos como S/MIME. CardDAV fornece contexto de coleção e ETags; WebDAV Sync enumera mudanças a partir de um token.

Cada camada emite uma prova diferente. A assinatura de transporte pode ligar bytes a uma credencial. O ETag identifica uma versão. O token delimita alterações.

Nenhum deles decide que dois telefones são iguais. Um remetente autenticado pode não ter poder sobre todos os campos. Uma gravação contra o ETag correto pode conter uma inferência errada. Uma lista completa de recursos alterados não explica uma exclusão.

A cadeia auditável separa: identidade de transporte, autorização, versão, motivo do pareamento das fichas, correspondências obrigatórias, correspondências discricionárias, resolução de conflito, projeção armazenada e resultado observado.

SOURCE e REV são sinais grossos

SOURCE pode apontar para a origem de uma ficha e REV indicar sua última atualização. São úteis contra dados envelhecidos.

Uma ficha pode juntar e-mail corporativo, celular informado pelo usuário e contato de emergência importado. Uma única fonte e uma única data não descrevem a procedência e idade de cada valor, nem a autorização de uma fusão específica.

Não é preciso transformar vCard em protocolo de eventos. A aplicação que toma uma decisão sensível é que deve guardar evidência adicional. Quanto maior o efeito sobre pessoas e processos, mais completo deve ser o recibo.

Métricas de convergência precisam mostrar o caminho

Conte separadamente pareamentos por UID e por heurística; correspondências obrigatórias de PID e discricionárias; inconsistências de CLIENTPIDMAP; fusões desfeitas por usuários; valores descartados; simplificações sem mapa antigo-novo; e falhas de contato após sincronização.

Uma taxa alta de convergência pode esconder propagação eficiente de erros. Se as reversões aumentam, o motor está produzindo estado comum, não necessariamente estado correto.

vCard4-bis é forte porque mostra onde termina sua resposta. O formato possui a sintaxe e os vínculos determinísticos. O motor possui a heurística. A aplicação possui a política de conflito. O operador possui implantação e auditoria. A realidade confirma depois se o contato funcionou.

Quando o mapa entra em conflito, a certeza deve diminuir. Preserve as duas histórias antes de escolher uma. A especificação parou ali; a responsabilidade local começa exatamente naquele ponto.

Sources