Resumen

  • localizations asocia etiquetas RFC 5646 con PatchObjects; RFC 9553 copia la Card base, excluye ese mapa y aplica el parche elegido a la copia.
  • La regla de todo o nada evita una variante a medias, pero no demuestra que el texto sea oficial, que el autor tuviera permiso ni que los datos sigan vigentes.
  • La operación defendible conserva base, política de idioma, parche, autorización, salida y uso posterior como recibos distintos.

El renderizado oculta la dependencia

El usuario no ve una Card base y un conjunto de operaciones. Ve una ficha acabada. El nombre tiene la escritura esperada, el cargo está traducido y la dirección sigue el orden local. El sistema parece haber consultado una fuente completa para ese idioma.

RFC 9553 no exige tal duplicación. La Card puede declarar el idioma principal y contener localizations, un mapa cuyas claves son etiquetas de idioma y cuyos valores son PatchObjects. El consumidor determina una etiqueta, busca el valor correspondiente, crea una copia sin localizations, aplica todas las operaciones y usa la copia como variante localizada.

La variante hereda el uid, la versión del modelo y los campos no tocados. No nace con una historia propia ni con una verificación nueva. Por eso el resultado debe poder explicarse como función de dos entradas: una revisión concreta de la base y un parche concreto.

Guardar la vista como si fuera otro registro rompe esa relación. Después, una discrepancia puede corregirse en la base sin llegar a la copia; una corrección local puede sobrescribir un hecho común; dos sistemas pueden intercambiar derivados y confundir su coincidencia con confirmación independiente.

Un parche atómico no es una aprobación

PatchObject usa rutas basadas en un subconjunto de JSON Pointer. El slash inicial se presupone. Los componentes anteriores al último deben existir. Puede reemplazarse un elemento existente de un array, pero no usar para insertar o borrar. Dos rutas no pueden solaparse de modo que una sea prefijo de otra. El valor debe ser válido para la propiedad; null solo puede eliminar una propiedad opcional.

Si falla una sola operación, debe rechazarse el objeto entero. Está prohibido aplicar una parte. Esta decisión evita una localización híbrida accidental: por ejemplo, un nombre actualizado junto a una dirección que no pudo transformarse.

La atomicidad protege coherencia estructural. No juzga el contenido. Un título laboral falso puede tener el tipo correcto. Una transliteración inventada puede ajustarse a JSON. Un correo del atacante puede ser una cadena perfectamente válida.

Conviene separar los estados en la interfaz operativa: parche bien formado, parche aplicable a la base, origen autenticado, modificación autorizada, alias de identidad aprobado, dato vigente y resultado observado. “Localización correcta” no sustituye ninguno de ellos sin evidencia adicional.

La ruta envejece junto con la Card

El ejemplo de RFC 9553 permite reemplazar todo name, pero también cambiar solo titles/t1/name. Esa segunda forma conserva los demás miembros del título. Depende de que la estructura y la clave t1 mantengan el mismo significado.

Las claves Id de los mapas deben preservarse entre versiones de un objeto JSContact. Es una ayuda directa para parchear y referenciar. Pero el RFC aclara que repetir un Id en mapas o Cards diferentes no crea conexión semántica. t1 no es una identidad global.

Un parche revisado contra la huella A puede seguir aplicándose a B aunque el puesto representado por t1 haya cambiado. También puede fallar porque la clave desapareció. O puede seguir siendo correcto si la nueva revisión solo cambió otro campo. El parser distingue el segundo caso; no decide por sí solo los otros dos.

updated indica la última modificación de los datos de la Card, no qué campo cambió ni quién lo autorizó. created tampoco prueba el origen del hecho. prodId identifica un producto, no una firma. version selecciona la versión registrada del modelo, no la revisión editorial de esa ficha.

Por eso el recibo necesita una huella de base y otra de parche. También debe registrar la revisión de negocio o el momento efectivo. Sin ese vínculo, una ruta válida puede sostener una afirmación obsoleta.

Elegir el idioma es ejercer política

Las etiquetas RFC 5646 permiten expresar idioma, escritura y, cuando corresponde, región. RFC 9553 empieza el algoritmo pidiendo que se determine la etiqueta. Esa frase deja a la aplicación una decisión real: qué preferencia usar, si aceptar una coincidencia más general, cómo ordenar escrituras y cuándo caer al contenido principal.

El formato no convierte esa política en una verdad universal. es-MX, es y una preferencia de escritura pueden producir decisiones distintas según el producto. Un fallback silencioso puede ser práctico, pero debe registrarse si el resultado alimenta una acción importante.

La etiqueta tampoco certifica la calidad ni el estatus del texto. El nombre alternativo de una institución puede ser oficial, consuetudinario, traducido, transliterado o inventado. Un nombre personal en otra escritura puede ser una forma original verificada o una aproximación editorial.

RFC 9553 transporta la variante; no la asciende a alias oficial. Un sistema responsable adjunta la fuente que avala el nombre protegido o declara que se trata de presentación no canónica. Localizar la interfaz no da licencia para reinventar identidades.

El atacante también puede localizar

Las consideraciones de seguridad califican los datos de contacto como especialmente sensibles. Pueden revelar identidad, ubicación, credenciales, empleo, intereses y relaciones. El RFC enumera escucha, repetición, inserción, borrado, modificación y ataques en ruta.

Su ejemplo central es operativo: un actor puede usar el nombre de una víctima y reemplazar los medios de contacto por los suyos. Una variante bien escrita puede hacer la usurpación más convincente. El lector confía en la gramática y en el formato local mientras el teléfono conduce a otra persona.

Los sistemas con consecuencias reales deben autenticar los datos recibidos y asegurar que el cambio viene de una entidad autorizada. El documento, sin embargo, solo define el formato. La API, el almacenamiento y el transporte deben aportar los controles.

Esto produce varias preguntas. ¿Quién entregó el objeto? ¿Quién firmó el parche? ¿Qué campos podía modificar? ¿La persona o institución aprobó ese nombre? ¿Se verificó el correo después del cambio? Una conexión segura puede responder la primera, pero no todas las demás.

La validación semántica también tiene límites. Puede exigir que el cargo sea texto, no saber si el cargo existe. Puede validar una URI, no saber si la controla el sujeto. El sistema debe mantener la diferencia entre forma y hecho.

El registro IANA no certifica instancias

RFC 9553 registra JSContact 1.0 y establece registros para versiones, propiedades, tipos y valores enumerados. Las entradas pueden indicar desde qué versión existen y hasta cuál son válidas. Así, productores y consumidores comparten un vocabulario evolutivo.

El registro responde si una propiedad está definida, no si su valor es verdadero. La aceptación bajo una versión y una fotografía del registro es evidencia de interoperabilidad. No es evidencia de que un nombre sea oficial, una dirección sea actual o una relación esté consentida.

La etiqueta “JSContact válido” debe conservar ese alcance. Si una interfaz la convierte en “contacto verificado”, ha mezclado el gobierno de un formato con la autoridad sobre una persona.

Un recibo pequeño evita copias soberanas

La cadena mínima conserva el uid, la versión JSContact, la huella y revisión de la base; la petición o regla que eligió la etiqueta; el PatchObject exacto, su fuente y autorización; el resultado atómico; la huella de salida; y el consumidor posterior.

Si cambia un nombre de persona u organización, se añade la evidencia del alias o la transliteración. Si cambia un correo o teléfono, se registra la comprobación y la acción que dependió de él. Si el resultado solo se mostró, no se declara contacto exitoso.

Cuando la base cambia, esa cadena permite decidir. Un parche puede seguir siendo válido, requerir revisión o quedar roto. La respuesta no consiste en mantener nueve copias y esperar que converjan.

La localización aumenta el acceso cuando conserva su naturaleza de proyección. Pierde confianza cuando el sistema borra el camino que une la vista con los hechos y decisiones que la produjeron.

Fuentes