Resumen

  • RFC 3676 añadió DelSp para diferenciar el espacio que ya pertenecía al texto de aquel que el emisor inserta solo como señal de continuidad.
  • El valor predeterminado es no. Para envolver texto en sistemas de escritura donde el espacio ASCII es raro o inexistente, la técnica nueva exige DelSp=yes, de modo que el receptor quite el marcador en vez de introducir un carácter en el texto reconstruido.

Un espacio al final de línea puede significar dos cosas. En text/plain; format=flowed, quizá el párrafo sigue debajo del ancho de la ventana. Pero ¿ese espacio separaba dos palabras desde el principio, o lo agregó el programa para marcar un salto blando? Publicada en 2004, la RFC 3676 hizo explícita la diferencia mediante el parámetro DelSp. Sustituyó a la RFC 2646 y mantuvo el texto adaptable, añadiendo una señal sobre cómo recomponer sus líneas. (§§4–4.2.)

El método anterior solo permitía cortar donde ya había un espacio entre palabras. El emisor colocaba CRLF después de ese separador. Al recibir el mensaje, el cliente unía las líneas físicas y conservaba el espacio. La RFC recomienda DelSp=no para ese método: el espacio formaba parte del contenido, no era una instrucción de maquetación que hubiera que borrar.

Ese método no sirve siempre en idiomas donde el espacio ASCII se usa poco o no se usa. Puede que no haya una separación natural en la que envolver la línea. La técnica nueva inserta SP CRLF en el punto elegido. El espacio final marca la continuación y, con DelSp=yes, el receptor elimina ese marcador al unir las líneas. Si lo conservara, una transformación visual añadiría un carácter ausente del texto original. Por eso RFC 3676 exige DelSp=yes al usar la técnica de inserción. No es un detector lingüístico: el emisor declara la regla que aplicó. (§§4.1–4.2.)

La ausencia del parámetro tampoco es ambigua para el protocolo. Si falta DelSp o su valor no se reconoce, el receptor supone no. Usar DelSp sin Format=Flowed no está definido; fuera de text/plain; format=flowed, los receptores DEBERÍAN ignorarlo. Así, el cliente no debe adivinar que el espacio final era sintético. El valor por defecto conserva la interpretación anterior, pero no puede recuperar la intención si se perdió el parámetro necesario.

También importa de qué lado del espacio se inserta el corte. Si el emisor coloca el marcador justo antes de un espacio original, este pasa a ser el primer carácter de la línea siguiente. El «space-stuffing» protege líneas que empiezan por un espacio, > o From ; la posición elegida activa una regla adicional. RFC 3676 recomienda insertar SP CRLF después del espacio ya existente. Así, el separador de las palabras y el marcador de corte siguen siendo elementos distintos. (§§4.2, 4.4.)

El alcance de la especificación es concreto: describe un formato de transmisión para text/plain, no el almacenamiento de archivos locales. La codificación de transferencia MIME es otra capa. La RFC también fija el orden entre preparar el texto flowed, firmar y volver a presentarlo; ese asunto criptográfico pertenece a la cobertura separada de RFC 2646 y aquí no se repite. Tampoco se afirma que un cliente concreto siguiera la regla. La lente de Note 65 de Lu Heng obliga a separar lo que dice el estándar de lo que hace el código que realmente corre. Para saber qué vieron los usuarios harían falta versiones identificadas y mensajes capturados.

Fuentes

  • RFC 3676, en especial §§4.1–4.2 y el apéndice A.
  • RFC 2646, especificación anterior del texto flowed.
  • RFC 2046, marco de tipos de medios MIME.
  • RFC 2045, contexto del cuerpo de los mensajes y la codificación de transferencia MIME.
  • Lu Heng, Note 65, lente analítica declarada, no prueba de implementación.