Resumen

  • draft-ietf-calext-vcard4-bis-00 obliga a reconocer ciertas tarjetas y propiedades mediante UID y PID, prohíbe otras coincidencias y deja el resto a la discreción del motor.
  • La ficha resultante demuestra qué estado se guardó. No demuestra, sin un registro externo, qué normalización se aplicó, por qué una heurística fusionó valores o quién autorizó la decisión.

La misma edición paralela produce dos respuestas

Dos dispositivos parten de una misma ficha. Mientras están desconectados, cada uno añade una dirección de correo y un teléfono. Las cuatro propiedades reciben identidades ligadas a sus respectivos contextos de origen.

Al reencontrarse las fichas, las direcciones nuevas no comparten un PID global. El motor no las considera la misma propiedad y conserva ambas. Los teléfonos tampoco comparten PID global, pero sus cadenas visibles coinciden. El ejemplo de la revisión 00 supone que un motor especialmente inteligente reconoce una sola realidad y los fusiona.

Esa asimetría contiene toda la cuestión editorial. El estándar no ordena unir los teléfonos; lo permite. El motor pudo acertar porque ambos usuarios introdujeron el mismo número. También pudo ocultar una diferencia no codificada: una extensión, un contexto profesional, una fuente más fiable o una obligación de conservar ambos orígenes.

La vCard final es válida en ambos casos. Por eso la validez no puede ser el único comprobante.

La revisión 00 coordina un formato, no certifica un despliegue

La revisión 00 de vCard Format Specification está fechada el 2 de julio de 2026 y expira el 3 de enero de 2027. Es un Internet-Draft del grupo CALENDAR EXTENSIONS, destinado a Standards Track, que sustituiría a RFC 6350 si fuese aprobado. Todavía no es un RFC.

Tampoco es una declaración de que un producto haya implementado la revisión, que dos proveedores ejecuten las mismas heurísticas o que una ficha represente correctamente a una persona real. El documento define cómo intercambiar nombres, direcciones, teléfonos, organizaciones, fotografías, claves y relaciones. Esa coordinación es importante, pero su autoridad termina en el terreno que define.

La doctrina de docs/heng-lu-note.md exige separar publicación, implementación, uso y resultado. Un formato aceptado por un parser no demuestra que el motor de sincronización eligió bien. Una sincronización sin errores no demuestra que el número siga perteneciendo al contacto. Un registro convergente no demuestra que la organización autorizó el borrado de una alternativa.

La especificación mínima puede fijar identificadores y prohibiciones comunes sin convertirse en gobierno permanente de cada conflicto. La decisión futura permanece localizada. La responsabilidad también.

UID decide qué fichas entran en la misma conversación

La sincronización se define como la fusión inteligente de dos representaciones del mismo objeto. Para iniciar esa fusión, las fichas con UID equivalentes deben coincidir.

La equivalencia distingue URI válidos de texto libre. Los URI siguen RFC 3986; las demás formas se comparan carácter por carácter después de retirar el escape propio de vCard. Esta regla proporciona una identidad de registro estable cuando una ficha compartida evoluciona en varios dispositivos.

No proporciona una identidad humana verificada. UID tiene cardinalidad *1: puede aparecer una vez como máximo, pero no es obligatorio en todos los casos. Cuando los UID no resuelven la cuestión, el motor puede decidir que dos fichas representan el mismo objeto. Incluso un UID idéntico podría haber sido copiado de manera incorrecta o maliciosa.

Por tanto, UID da una respuesta procedural: estas representaciones deben reconciliarse. No prueba que quien envió una copia tuviese autoridad sobre todos sus campos, que el sujeto consintiese la unión o que ambas copias estén actualizadas.

PID convierte una identidad local en una relación comparable

Dentro de una ficha coincidente hay que reconocer cada propiedad. El primer campo de PID nombra un valor local. El segundo campo indica una fuente mediante un entero pequeño cuyo alcance se limita a esa instancia de vCard.

CLIENTPIDMAP asocia el entero de fuente con un URI y le da contexto global. Cada fuente utilizada necesita una entrada correspondiente, y el identificador cero está prohibido. Cuando dos PID tienen el mismo valor local y sus fuentes remiten a URI equivalentes, representan el mismo valor global.

La separación es deliberada. El número 1 puede existir en miles de dispositivos sin pretender ser global. La tabla de cada ficha lo sitúa en un espacio de origen concreto.

Pero la tabla no firma nada. Un URI con forma de UUID no demuestra posesión, autoría ni mandato. Permite comparar nombres. La autenticación de la fuente y su autorización para cambiar un campo pertenecen a otras capas.

Esta precisión evita dos errores opuestos: tratar todos los enteros iguales como la misma fuente, o convertir una simple referencia global en prueba de custodia.

Los MUST son invariantes; los MAY son poder local

La revisión 00 impone límites claros. Las propiedades de fichas no coincidentes no deben compararse. Propiedades con nombres diferentes tampoco. Entre fichas ya coincidentes, dos propiedades del mismo nombre y cardinalidad máxima uno deben corresponder. Lo mismo ocurre cuando sus PID coinciden.

Estas reglas impiden que la similitud textual rompa la estructura. Un TEL no se vuelve EMAIL. Un campo de otra persona no entra en la ficha actual. Una identidad de propiedad reconocida no puede ignorarse sólo porque un proveedor prefiera su propio criterio.

En los demás casos, propiedades del mismo nombre pueden coincidir a discreción del motor. Ese MAY reconoce una realidad: las representaciones humanas tienen variantes que ningún esquema universal puede resolver con seguridad.

Sin embargo, MAY no transfiere la responsabilidad al IETF. El motor que normaliza dos números, aproxima dos nombres o deduce una dirección equivalente está ejerciendo una política. Debe registrar la versión del algoritmo, los datos comparados, la confianza, el umbral y la acción elegida.

Si no existe ese comprobante, el operador sólo puede mostrar el resultado y afirmar que el estándar permitía decidir. Permitir no es decidir, y decidir no es justificar.

El teléfono unido puede ocultar una diferencia real

Dos cadenas telefónicas iguales parecen el caso fácil. Aun así, la igualdad textual puede no agotar el significado. Un sistema puede haber eliminado separadores o prefijos; otro puede tratar una extensión como metadato; una fuente puede ser corporativa y otra personal; una propiedad puede estar verificada y otra ser una sugerencia importada.

El resultado del ejemplo conserva ambos PID en la propiedad unificada. Esa conservación es mejor que borrar una identidad sin rastro. Indica que dos líneas de edición alimentaron el mismo TEL.

No explica por qué se consideraron equivalentes. Para eso hace falta un recibo con los valores originales, la forma normalizada, las tablas CLIENTPIDMAP, la regla aplicada, las alternativas preservadas y cualquier confirmación humana. También debe registrar si la fusión es reversible.

La reversibilidad cambia el riesgo. Una sugerencia visual que el usuario puede separar tiene consecuencias limitadas. Una fusión que se propaga a un directorio empresarial y elimina una ruta de contacto necesita un nivel de autoridad mucho mayor.

Una tabla de fuentes inconsistente obliga a detener la certeza

CLIENTPIDMAP se trata aparte de las propiedades ordinarias. El motor debe mantener la consistencia entre las tablas de fichas coincidentes. Cuando no son consistentes, la especificación deja el resultado al motor y no lo define.

La inconsistencia puede ser una renumeración legítima o la señal de una copia dañada, una colisión o una sustitución de origen. La falta de una regla universal es razonable porque las arquitecturas de confianza difieren.

Lo que no es razonable es resolverla de forma destructiva y silenciosa. Una implementación puede poner el caso en cuarentena, conservar ambos contextos, pedir confirmación o consultar un historial autenticado. Debe preservar las entradas y el motivo de la decisión.

Si el producto sobrescribe una tabla y luego atribuye el resultado a «vCard», ha ampliado la autoridad del formato para ocultar una elección local.

La simplificación global cambia el tipo de evidencia

Después de converger, el ejemplo reduce dos contextos de fuente a uno. Renumera propiedades y elimina una CLIENTPIDMAP ya innecesaria para el estado futuro. La ficha se acorta.

El documento dice que el procedimiento detallado no está especificado. Eso significa que dos implementaciones pueden producir proyecciones distintas aunque ambas consideren equivalente el estado final.

La compresión no es intrínsecamente mala. Los sistemas necesitan instantáneas, recolección de basura y vistas materializadas. Mantener toda la historia dentro de cada objeto portátil sería costoso e incómodo.

La disciplina consiste en guardar la historia fuera del objeto que se optimiza. Antes de simplificar, se registran el hash de entrada, las fuentes, el mapa de renumeración, los conflictos y la regla. Después, se registra el hash de salida. La vCard compacta responde qué se sirve ahora; el recibo responde cómo se llegó allí.

Cuando sólo queda la ficha compacta, puede hablar de estado, no de causalidad.

S/MIME, ETag y sync-token contestan otras preguntas

Las vCards no incluyen autenticación ni confidencialidad inherentes. El borrador menciona protecciones de transporte como S/MIME. CardDAV emplea validadores de recursos y WebDAV Sync permite enumerar cambios de una colección.

Una envoltura autenticada prueba que ciertos bytes llegaron íntegros desde una credencial bajo una configuración de confianza. Un ETag ayuda a saber qué versión se modificó. Un token delimita qué recursos cambiaron desde una sincronización anterior.

Ninguno decide que dos correos son distintos mientras dos teléfonos son uno. Tampoco prueba que el remitente autenticado posea autoridad sobre cada detalle de la persona representada.

Por eso el flujo válido no es «transporte seguro, luego verdad». Es una cadena: transporte, autorización, versión de recurso, coincidencia de ficha, coincidencia de propiedad, resolución de conflicto, almacenamiento, propagación y resultado observado. Cada paso emite su propio comprobante.

SOURCE y REV ayudan a refrescar, no a reconstruir

SOURCE puede indicar dónde obtener información y REV cuándo se actualizó la ficha. Son señales útiles contra la obsolescencia, un riesgo que el borrador reconoce.

Una ficha puede mezclar valores de varias procedencias. Un solo SOURCE y una sola fecha REV no describen la edad y autoridad de cada propiedad, ni la decisión que unió dos valores. No deben cargarse con una función que el formato no les asignó.

La aplicación que realiza una fusión sensible conserva metadatos más ricos. La aplicación que sólo muestra una tarjeta recibida puede limitarse al formato portátil. La cantidad de evidencia debe seguir la capacidad de causar daño.

Convergencia no equivale a corrección

La fortaleza de vCard4-bis está en dibujar sus límites. Define coincidencias obligatorias y prohibidas. Deja casos ambiguos al motor. No presenta una simplificación ilustrativa como algoritmo final.

El formato gobierna la forma del intercambio. El motor gobierna la heurística. La aplicación gobierna el conflicto. El operador gobierna despliegue y auditoría. El usuario o la institución gobierna la acción. La realidad dirá después si el teléfono funcionaba y pertenecía al destinatario esperado.

Una métrica de sincronización que sólo cuente cuántas fichas convergieron ignora la parte importante. También hay que medir fusiones discrecionales, reversiones, campos descartados, conflictos de fuente y errores posteriores.

El objetivo no es impedir que un motor sea inteligente. Es exigir que la inteligencia deje recibo. Los dos correos y el teléfono unificado pueden ser el resultado correcto. Lo que no puede hacer la ficha final es probarlo por sí sola.

Sources