Resumen

  • RFC 9982 establece que uid es opcional para una Card JSContact 2.0 y que una vCard sin UID no debe recibir un uid inventado durante esa conversión.
  • La versión, el análisis correcto o una clave local estable pueden describir un registro. No prueban por sí mismos la identidad de la entidad, la validez de una relación ni el derecho a consolidar datos.

En JSContact anterior, toda Card necesitaba uid. Eso acomodaba protocolos de sincronización que necesitan un manejador estable, pero hacía que el modelo difiriera de vCard, donde UID es opcional. La conversión de una vCard sin ese campo obligaba antes a generar un valor, aunque no tenía por qué repetirse entre implementaciones ni entre dos ejecuciones. Un identificador creado para satisfacer una regla de forma podía convertirse después en el soporte de members o relatedTo, como si fuera una declaración del contacto original.

RFC 9982 cambia el orden de las afirmaciones. Una Card 2.0 sin uid puede ser válida; no debe rechazarse sólo por esa ausencia. Pero tampoco puede introducirse como miembro de grupo o destino de una relación de otra Card. El estándar no niega la utilidad de la tarjeta. Niega únicamente que el modelo posea el identificador requerido para construir ese enlace. La restricción conserva información sin convertir la carencia de procedencia en una relación durable.

La regla de conversión sostiene esa cautela. Si la vCard de origen no trae UID, al convertir a versión 2.0 o posterior se debe dejar ausente uid. Para salida 1.0, el valor aún debía generarse de manera específica de implementación, con una recomendación de estabilidad que no resolvía la ambigüedad entre sistemas. La nueva norma no convierte el hueco en un hecho. Evita que una clave efímera sea tratada como una referencia interoperable.

Conviene enumerar las capas que un tablero suele fundir: igualdad de bytes, continuidad de una clave local, procedencia del registro, resolución de una persona u organización, vigencia de una relación, consentimiento, derecho a cambiar la fuente y resultado de la reconciliación. uid vive en la capa de estructura y referencia del modelo. Una cadena presente no es una credencial, una firma, un nombre legal, una prueba de control de cuenta ni una autorización para fusionar. La inscripción de JSCOMPS en IANA mejora el registro de parámetros de vCard; tampoco certifica la fidelidad semántica de una conversión.

CardDAV o JMAP Contacts pueden requerir una clave porque su protocolo necesita sincronizar objetos. RDAP puede no necesitarla. La necesidad de un protocolo es real y limitada. No autoriza a inventar una identidad cuando el origen no la afirmó. El mínimo común de Heng Lu resulta valioso precisamente por eso: permite intercambiar el registro sin colonizar las decisiones locales de equivalencia y gobierno.