Resumen

  • RFC 10050 define perfiles como conjuntos identificados y versionados de restricciones sobre propiedades, tipos y valores registrados de JSContact. Solo pueden estrechar las reglas de base.
  • El objeto Card no contiene una declaración universal de perfil y una misma tarjeta puede cumplir más de uno. El protocolo envolvente debe seleccionar y transmitir la identidad aplicable y decidir sus condiciones adicionales.
  • El registro IANA conserva el significado histórico de cada par nombre-versión. La inscripción facilita interoperabilidad documental, pero no certifica que el contenido del perfil sea seguro o apropiado.

El mismo objeto puede recibir tres respuestas diferentes sin que ninguna sea un error. “Sí” a la pregunta de si es JSContact válido. “Sí” a la pregunta de si cumple un perfil concreto. “No” a la pregunta de si un protocolo determinado debe aceptarlo.

La tercera respuesta puede deberse a una versión declarada incorrectamente, a una propiedad que el perfil tolera pero el protocolo prohíbe, o a una regla de negociación que existe fuera de la tarjeta. RFC 10050, publicado en septiembre de 2026 como Proposed Standard, hace visible esa separación y le da una estructura operativa.

Un perfil reduce el espacio posible

RFC 9553 ofrece un modelo general para datos de contacto. Un servicio concreto casi nunca necesita toda esa flexibilidad. El perfil puede volver obligatoria una propiedad opcional, excluir otra que JSContact admite, reducir los tipos posibles o acotar valores.

No puede operar en sentido contrario. Si algo es inválido según JSContact, un perfil no lo rescata. De ahí se desprende una cadena de comprobación: reglas de base, restricciones del perfil y política del protocolo. Cambiar el orden u omitir un eslabón produce una afirmación diferente.

La identidad del perfil está formada por un nombre sensible a mayúsculas y minúsculas y una versión entera positiva. El contenido asociado a ese par permanece inmutable en el registro. Una revisión usa un número superior y las versiones anteriores siguen disponibles.

Esta regla protege el pasado. Un registro que dice “perfil X, versión 4” debe conservar el mismo significado cuando aparezca la versión 5. De lo contrario, una auditoría futura no podría saber qué restricciones respaldaron una aceptación antigua.

El conjunto de propiedades no es plano

Las tarjetas contienen objetos anidados. Un tipo autorizado para una propiedad puede introducir otras propiedades y estas, a su vez, nuevas estructuras. RFC 10050 exige que el conjunto admitido se evalúe recursivamente hasta alcanzar su cierre.

Una lista blanca que solo mira el primer nivel puede aprobar una rama prohibida. Otra implementación excesivamente literal puede rechazar una propiedad anidada que sí es alcanzable a través de un tipo permitido. Los JSON Pointer de RFC 6901 permiten nombrar elementos con precisión, pero no sustituyen el recorrido del modelo.

Por eso la conformidad no debería guardarse como una marca aislada. Conviene retener la versión base, el nombre y la versión del perfil, la versión del validador, las rutas recorridas y la regla exacta que falló o permitió el dato.

La tarjeta no declara su propio pasaporte

RFC 10050 no añade un campo general de perfil al objeto Card. Tampoco impone un contenedor único para nombre y versión. La decisión pertenece al protocolo que usa la tarjeta.

La razón comienza con la multiplicidad: una tarjeta puede satisfacer simultáneamente dos o más perfiles. Un único rótulo sería falso por omisión; una lista tampoco explicaría cuál fue acordado para la transacción. Además, declarar no es demostrar. El receptor debe validar de manera independiente y aplicar las reglas que su protocolo establezca sobre negociación, errores y restricciones extra.

Un diseño observable mantiene tres salidas: validez del JSContact, conformidad con un perfil identificado y validez protocolaria. Un solo valid elimina información decisiva y favorece errores de interoperabilidad difíciles de diagnosticar.

Registrar no es aprobar

Las altas nuevas siguen la política Specification Required de RFC 8126; los cambios de referencia usan Expert Review y el IETF controla los cambios. Los expertos designados comprueban cuestiones como unicidad y sintaxis del identificador, propiedades y tipos conocidos, estabilidad de la especificación y aumento del número de versión.

RFC 10050 aclara que no tienen obligación de juzgar el contenido sustantivo. Estar en el registro no prueba que el perfil minimice datos, tenga una buena política de privacidad o convenga a una industria. El registro entrega una referencia durable; el riesgo sigue en manos de quien adopta el perfil.

Durante esta revisión, la página IANA de JSContact mostraba la sección de perfiles sin entradas y a los expertos aún sin asignar. La página indicaba como última actualización el 28 de mayo de 2026 y todavía citaba un Internet-Draft, anterior a la publicación del RFC en septiembre. Es una observación fechada, no una acusación: ambos procesos pueden actualizarse a ritmos distintos.

Precisamente por eso, una organización debe conservar su propia constancia de custodia: nombre y versión, copia o hash de la especificación referenciada, fecha de obtención, versión base de JSContact, software validador, cierre recursivo calculado, forma en que el protocolo transmitió la selección y reglas adicionales. La decisión queda así reproducible aunque la página cambie.

Fuentes