Resumen

  • RFC 3459 añadió Handling=REQUIRED|OPTIONAL a partes MIME individuales: perder una parte REQUIRED hacía fallar todo el mensaje; una OPTIONAL podía eliminarse en silencio sin convertir la entrega en fracaso.
  • Las partes sin marca y los valores desconocidos se trataban como REQUIRED; en firmas y cifrado, la ubicación de la marca decidía si la pasarela podía transformar o debía rechazar.

La entrega parcial necesitaba un contrato del remitente

El correo Internet general esperaba que un receptor MIME conservara o pusiera a disposición todas las partes, aunque no tuviera el visor adecuado. Un sistema de voz podía ser más limitado: almacenar audio y fax, pero no vídeo o un documento binario. Una pasarela que conocía las capacidades del extremo tenía que quitar a veces lo que este no aceptaba.

RFC 3459, de enero de 2003, hizo explícita esa transformación. El texto, la ficha del RFC Editor, el expediente, el historial, las referencias, las citas y los errata delimitan la evidencia. La norma actualizó RFC 3204 al separar Handling del transporte ISUP/QSIG.

Como parámetro de Content-Disposition, REQUIRED indicaba que el remitente no consideraba entregado el mensaje si esa parte no pasaba. Un fallo hacía fracasar el conjunto. OPTIONAL permitía borrar silenciosamente una parte incapaz de llegar y prohibía devolver fallo salvo que también fallara una REQUIRED.

No era una escala de importancia o urgencia. Distribuía autoridad de transformación y consecuencias. Un cliente podía agregar material auxiliar sin conocimiento del usuario; declararlo opcional evitaba que un sistema de voz rechazara audio útil por un adjunto indiferente para el remitente.

El borrado, el fracaso y el aviso eran decisiones distintas

El valor por defecto era conservador: toda parte sin marca era REQUIRED, igual que cualquier valor futuro no reconocido. Un agente antiguo podía ignorar el parámetro según MIME; una pasarela nueva no podía borrar en silencio una semántica desconocida. RFC 2045 aportaba la base MIME y RFC 2421 el entorno de voz limitado.

La criticidad no solicitaba por sí sola un recibo. Los DSN seguían RFC 3461, los MDN RFC 3798, y la incapacidad de almacenar o representar podía usar el 5.6.1 de RFC 3463. Una pasarela anterior a la entrega podía generar DSN; un agente posterior, MDN; SIP respondía con estado, incluido 415 para RFC 3204. La función y la topología definían el comprobante.

En la criptografía, la ubicación de la marca era política

Con RFC 1847, marcar el contenedor multipart/signed REQUIRED exigía paso intacto y verificación extremo a extremo; un terminal incapaz obligaba al rechazo. Marcar REQUIRED el objeto de control de firma permitía verificar en la pasarela, pero una firma fallida seguía causando rechazo. Si la firma era OPTIONAL y el material firmado REQUIRED, la pasarela podía retirar la firma para un extremo incapaz, aunque verificar y advertir manipulación seguía siendo muy recomendable. RFC 2480 aportaba reglas relacionadas.

Con cifrado, un objeto de control REQUIRED exigía cifrado extremo a extremo. Si era OPTIONAL, una pasarela capaz podía descifrar y enviar texto claro a un extremo incapaz; el remitente concedía esa autorización al colocar allí la marca. Ocultar la marca dentro de los datos cifrados obligaba a descifrar para descubrirla, por lo que el contenido no marcado seguía siendo REQUIRED.

RFC 3238 ofrecía el marco OPES de consentimiento y notificación. Las posteriores capas de realidad de Heng Lu separan marca, capacidad declarada, transformación real y resultado. La primacía del código en funcionamiento pide comparar los árboles MIME antes y después. Son lentes editoriales posteriores, no prueba de intención privada.

RFC 3459 convirtió la pérdida parcial de accidente invisible en reparto explícito de consecuencias. Una parte opcional podía desaparecer y la entrega seguir siendo válida; una parte requerida diminuta podía invalidar todo.

Fuentes