Resumen

  • Las continuaciones de RFC 2231 empiezan en *0, avanzan sin huecos y sitúan el juego de caracteres y el idioma opcional al comienzo del primer segmento codificado. Los índices, no el orden físico, gobiernan la recomposición.
  • Un filename bien formado continúa siendo una sugerencia de Content-Disposition. RFC 2183 exige retirar rutas, evitar sobrescrituras y ubicaciones peligrosas, y no ejecutar nada sin una acción explícita.

Un solo valor, varias piezas

Hay mensajes en los que el nombre que ve el usuario nunca viajó como una cadena única. Puede haber llegado así, en un ejemplo didáctico:

filename*0*=utf-8'en'Quarterly%20; filename*1*=review%20; filename*2=final.pdf

La sección cero declara UTF-8 y un idioma opcional, además de iniciar el valor. La uno añade material con escapes de porcentaje. La dos cierra sin marca de codificación. Si no hay huecos ni duplicados ambiguos, el resultado lógico es Quarterly review final.pdf.

El receptor no puede limitarse a leer de izquierda a derecha. Los parámetros MIME no adquieren significado por su posición y un intermediario puede reordenarlos. RFC 2231 coloca el orden dentro del nombre: cero primero, después uno, dos y así sucesivamente. No admite saltos ni ceros iniciales. Antes de interpretar caracteres hay que agrupar por nombre base, validar una secuencia completa y concatenar por índice.

También importa no decodificar cada fragmento como texto independiente. El juego de caracteres y el idioma se declaran una sola vez al principio. La frontera de una continuación es una frontera de transporte, no necesariamente de carácter. Los octetos de un carácter UTF-8 pueden quedar repartidos entre dos secciones; decodificarlas por separado puede producir símbolos de reemplazo o resultados distintos en dos aplicaciones.

La secuencia operacional prudente es: analizar nombres, validar la serie, ordenar y unir la carga, revertir los escapes de porcentaje en octetos, aplicar el juego de caracteres declarado y solo entonces entregar el texto a una política de disposición. La sección de seguridad de RFC 2231 es escueta, pero su gramática y la declaración inicial única sostienen esta separación. Cada etapa demuestra algo distinto y nada más.

Haberlo entendido no significa obedecerlo

RFC 2231 resolvió un problema de representación. No convirtió una etiqueta remota en una orden local. RFC 2183, la especificación de Content-Disposition actualizada por ese mecanismo, define filename como un nombre sugerido para guardar una parte del cuerpo.

El agente de usuario receptor no debe usarlo a ciegas. Debe ignorar la información de directorios y conservar, como mucho, el último componente. Debe impedir que el nombre sobrescriba un archivo existente, alcance zonas de sistema o arranque, nombre dispositivos o tuberías, o coloque un ejecutable en una ruta peligrosa. Guardar un adjunto tampoco debe bastar para ejecutarlo sin que el usuario lo inicie de forma explícita.

Nada de esto desaparece porque la cadena UTF-8 se haya reconstruido bien. Puede contener ../, una ruta absoluta, controles invisibles, órdenes bidireccionales, nombres reservados o una extensión que engañe al sistema. Decodificar porcentajes no sanea. Validar el juego de caracteres no autentica a quien envió el mensaje. Comparar nombre y Content-Type no certifica los octetos. La sintaxis no autoriza guardar, reemplazar, abrir, ejecutar ni atribuir.

Por eso hacen falta límites visibles. El parser MIME decide si la serie es coherente. El decodificador determina qué texto representan los octetos. Una regla local produce un nombre seguro. El almacenamiento confina el destino y resuelve colisiones. El usuario u otra política autorizada decide si se abre o ejecuta. Ningún aprobado anterior sirve como permiso para la etapa siguiente.

La coautoría tampoco admite piezas ajenas

RFC 2231 lleva los nombres de Ned Freed y Keith Moore. Su antecedente, RFC 2184, también fue firmado por ambos. Esa es la frontera documental de la autoría del mecanismo de continuaciones MIME.

Patrik Fältström hizo aportes relevantes a la internacionalización de Internet, pero no figura como autor de RFC 2231 ni de RFC 2184. RFC 3490, sobre la versión original de IDNA, sí reúne a Fältström con Paul Hoffman y Adam Costello. Convertir la cercanía temática en una coautoría inexistente rompería la procedencia: documentos vecinos pueden compartir vocabulario sin compartir autores ni contrato técnico.

El trabajo más amplio de Freed está registrado en IETF Datatracker. Nathaniel Borenstein recordó cómo su interés por enriquecer el correo se complementó con la atención de Freed a la robustez y la interoperabilidad. RFC 2045 define la estructura de los cuerpos MIME; RFC 2047 trata texto no ASCII en cabeceras; RFC 2231 aborda el problema más estrecho de los valores de parámetros.

Ese alcance acotado evita inferencias peligrosas. Un asterisco no activa por sí solo las reglas en cualquier protocolo: la especificación correspondiente debe adoptarlas. Transportar un nombre internacional no lo convierte en afirmación de identidad ni en fuente de autoridad.

HTTP heredó menos de lo que parece

RFC 8187 adapta para HTTP una forma emparentada de parámetro codificado y obliga a admitir UTF-8, pero excluye las continuaciones de RFC 2231 porque no eran necesarias allí. La genealogía técnica no implica copiar toda la superficie.

RFC 6266 mantiene el límite en Content-Disposition para HTTP: el nombre es orientativo. El destinatario elimina componentes de ruta, controla el directorio, neutraliza extensiones peligrosas y trata caracteres de control y nombres especiales. El servidor puede sugerir una etiqueta; no puede gobernar el sistema de archivos del cliente.

El legado de RFC 2231 es una doble exigencia. Para interoperar, hay que ser estricto con la numeración, la declaración inicial y el orden de decodificación. Para operar con seguridad, hay que ser igual de estricto con aquello que el resultado no prueba. Recuperar una cadena no equivale a confiar en ella.

Fuentes