Resumen

  • draft-ietf-nfsv4-internationalization-17 reconoce que los nombres de NFSv4 pueden compararse como octetos opacos o mediante reglas conscientes de Unicode, normalización y mayúsculas. El cliente no dispone de una forma general de descubrir toda la relación de equivalencia.
  • Una migración debería exigir un recibo de equivalencia del espacio de nombres: bytes exactos, forma devuelta, entorno, pruebas de colisión, capacidades observadas y cuestiones que el ensayo no pudo resolver.

La misma pantalla, dos identidades

Dos nombres pueden verse idénticos y estar hechos de secuencias Unicode distintas. También pueden verse diferentes y ser tratados por el servidor como variantes del mismo nombre. Ese desacuerdo entre apariencia e identidad rara vez se nota mientras todos los accesos pasan por el mismo sistema. Se vuelve decisivo cuando un volumen se replica, una copia se restaura o un servicio cambia de servidor.

El proyecto de internacionalización de NFSv4 ofrece una descripción realista del problema. La revisión 17 apareció el 11 de septiembre de 2026, después de los comentarios de la última llamada del IETF. Es un Internet-Draft activo de Standards Track, remitido al IESG; todavía no es un RFC y tampoco demuestra que una implementación concreta siga sus recomendaciones.

Su historia explica por qué conviene desconfiar de las etiquetas sencillas. Según el informe del responsable del documento, el diseño de internacionalización de NFSv4.1 no llegó a implantarse de la forma prevista. Las implementaciones principales señaladas siguieron en la práctica el planteamiento de NFSv4.0, ajeno a la interpretación de UTF-8, mientras que las funciones conscientes de Unicode quedaron limitadas o experimentales. El texto actual se apoya, por tanto, en gran medida en la conducta existente. No presupone que la norma haya creado la realidad; intenta describir la realidad que debe coordinar.

Cuando un nombre solo son bytes

Un sistema de archivos que no entiende UTF-8 acepta cada componente del nombre como una cadena opaca. La comparación correcta en ese régimen es octeto por octeto. Esto permite conservar nombres heredados en otras codificaciones e incluso secuencias que no constituyen UTF-8 válido. También significa que dos representaciones canónicamente equivalentes de un carácter Unicode siguen siendo nombres distintos si sus bytes difieren.

La propiedad es coherente y puede ser muy valiosa. Un archivo antiguo no cambia de identidad porque una biblioteca moderna prefiera otra forma. Sin embargo, el usuario que teclea lo que parece el mismo texto puede generar bytes distintos y recibir «no encontrado». La interfaz humana sugiere igualdad; el espacio de nombres conserva diferencia.

Un servidor consciente de UTF-8 dispone de otras opciones. Puede normalizar un nombre al guardarlo, o conservar la forma original y aceptar formas canónicamente equivalentes durante LOOKUP. Puede transformar variantes de mayúsculas o compararlas como iguales. La decisión efectiva puede proceder de la propia implementación, del sistema de archivos inferior o de una opción de configuración.

No existe una única política «Unicode». La equivalencia de mayúsculas puede depender del idioma y de preferencias del usuario. La versión de Unicode también importa, porque las clases de equivalencia pueden crecer cuando se incorporan nuevos caracteres. Una misma pila actualizada años después puede interpretar una consulta de modo diferente sin que haya cambiado un solo byte del directorio.

Un indicador de capacidad no es un contrato

NFSv4 cuenta con fs_charset_cap, pero la señal útil que ofrece es estrecha. El borrador la emplea para indicar que el servidor admite únicamente nombres UTF-8. El significado histórico de FSCHARSET_CAP4_CONTAINS_NON_UTF8 quedó poco claro; el texto recomienda que los servidores proporcionen su complemento y que los clientes lo ignoren. Si el atributo no existe, una búsqueda con una secuencia no UTF-8 puede aportar información sobre la aceptación.

Nada de eso responde por completo a la pregunta fundamental: ¿qué entradas considera iguales el servidor? El cliente no suele poder averiguar si hay normalización, qué versión de Unicode participa ni el conjunto exacto de equivalencias de mayúsculas. Una respuesta positiva solo enseña un punto de la función. Repetir el ensayo con varios nombres genera más puntos, no la función entera.

Esta diferencia se pierde con facilidad en inventarios y contratos. «Solo UTF-8» habla de admisión. «Consciente de Unicode» puede hablar de validación, almacenamiento o comparación. «No distingue mayúsculas» oculta las reglas lingüísticas. Para decidir si un nombre cruzará una frontera, hacen falta hechos más precisos.

El directorio no enumera todas las consultas válidas

READDIR permite ver el nombre que el servidor presenta, pero no todas las variantes que aceptaría para llegar al mismo objeto. Un servidor puede conservar una forma y reconocer otra durante la búsqueda. Por eso, leer el directorio y comparar localmente no reproduce necesariamente la semántica del servidor.

El efecto llega a las cachés. Un cliente que registra un resultado negativo según su propia igualdad puede mantener un «ausente» que el servidor habría resuelto con una forma equivalente. También puede omitir LOOKUP porque el nombre no coincide con la salida de READDIR, aunque el servidor sí lo aceptaría. El borrador pide al cliente estar preparado para la normalización, pero le advierte que no debe darla por hecha. Esa cautela es sensata precisamente porque la política permanece parcialmente oculta.

Ni siquiera conservar todos los bytes resuelve la operación futura. Es imprescindible para una copia forense, pero el destino puede rechazar esos bytes o atribuirles una nueva igualdad. Los datos están; el sistema ya no comparte la antigua manera de nombrarlos.

Migrar es someter los nombres a otro tribunal

Los planes de almacenamiento suelen contar objetos, metadatos, permisos y sumas de comprobación. Los nombres aparecen como rutas, no como decisiones. Sin embargo, al recrear una entrada en el destino se pregunta a un nuevo tribunal qué secuencias puede aceptar y cuáles se refieren a la misma cosa.

Si el origen distingue dos formas que el destino une, la copia puede chocar o sobrescribir. Si el origen une formas que el destino separa, una aplicación puede dejar de encontrar el archivo con la variante que siempre utilizó. Si el destino solo acepta UTF-8, ciertos nombres históricos no tendrán representación directa. Si las reglas de mayúsculas cambian, dos rutas distintas pueden competir.

Una prueba con nombres habituales apenas roza el riesgo. Favorece los archivos activos, las teclas disponibles y las bibliotecas actuales. Deja fuera los datos antiguos, los nombres creados en otro sistema operativo y las variantes que nadie recuerda porque el servidor las resolvía silenciosamente. La restauración puede descubrir el problema cuando el origen ya no existe. El failover puede descubrirlo bajo presión, cuando el contenido está replicado pero el software no puede referirse a él.

El recibo de equivalencia

La aprobación de una migración necesita una pieza de evidencia que pueda leer otra persona meses después. Propongo llamarla recibo de equivalencia del espacio de nombres. No forma parte de las obligaciones del borrador; es una capa operativa para no convertir una suposición en política.

El recibo identifica versión de NFS, producto y versión del servidor, sistema de archivos, opciones de exportación y montaje, sistema operativo, biblioteca Unicode y fecha. Conserva los componentes probados como bytes exactos, además de una representación visible segura. La segunda ayuda al equipo; la primera impide que una herramienta de documentación normalice sin avisar la propia evidencia.

El corpus combina nombres reales con pares diseñados: secuencias compuestas y descompuestas, variantes de mayúsculas relevantes, bytes históricos no UTF-8 y caracteres cuyo tratamiento pueda variar según la versión. En una zona aislada se anota si cada forma se puede crear, si LOOKUP devuelve el mismo filehandle, qué muestra READDIR, qué dice fs_charset_cap y qué ocurre después de eliminar o sortear las cachés negativas.

La prueba debe ejecutarse tanto en el origen como en el destino. Además, distingue observación, documentación del proveedor e inferencia. Una afirmación comercial no sustituye el ensayo; un ensayo tampoco demuestra todos los casos que el proveedor no permite observar. Las lagunas se conservan como lagunas.

Las colisiones y rechazos reciben una decisión: renombrado reversible, codificación de escape, aislamiento, servicio de compatibilidad o excepción aceptada. Toda transformación lleva una tabla duradera entre bytes originales, nombre de destino y contenido. Así, desactivar el origen no elimina la única explicación de cómo se tomaron las identidades.

El recibo no debe extender sus conclusiones a todas las cadenas del protocolo. El contenido de un enlace simbólico es opaco bajo reglas propias y los nombres de dominio no ASCII utilizan el marco de U-labels. La precisión consiste en afirmar poco, pero demostrarlo bien.

Dónde termina la afirmación

RFC 6943 documenta que las comparaciones incoherentes de identificadores pueden causar falsos positivos, falsos negativos, denegación de servicio y, en ciertos contextos, elevación de privilegios. Eso no equivale a atribuir un incidente a NFS ni a este borrador. Sí justifica revisar los nombres como una superficie de seguridad cuando una ruta interviene en autorización, ejecución o retención de registros.

El límite probatorio es nítido: una búsqueda exitosa demuestra que un espacio de nombres concreto resolvió una secuencia de bytes bajo su política vigente. No demuestra que otro export, cliente, sistema de archivos o versión de Unicode vaya a dictar la misma sentencia. La portabilidad no se deduce del éxito. Se documenta en la frontera.

Fuentes