¿Confusión de parámetros de "tipo de contenido" MIME RFC? Especificación RFC poco clara

Question

Estoy tratando de implementar un analizador mime básico para el multipart/related En C ++/Qt.

Hasta ahora he estado escribiendo algún código de analizador básico para encabezados, y estoy leyendo los RFC para tener una idea de cómo hacer todo lo más cerca posible de la especificación. Desafortunadamente, hay una parte en el RFC que me confunde un poco:

De RFC882 Sección 3.1.1:

Cada campo de encabezado se puede ver como una sola línea lógica de caracteres ASCII, que comprende un nombre de campo y un cuerpo de campo. Por conveniencia, la parte del cuerpo de campo de esta entidad conceptual se puede dividir en una representación de múltiples líneas; Esto se llama "plegado". La regla general es que donde sea que haya espacio lineal-blanco (no simplemente LWSP-Chars), se puede insertar un CRLF seguido inmediatamente por al menos un LWSP-Char. Así, la línea única

Muy bien, simplemente analizo un campo de encabezado y si un CRLF sigue con espacios blancos lineales, simplemente lo concierto de manera útil para dar como resultado una sola línea de encabezado. Procedamos ...

De RFC2045 Sección 5.1:

En la notación BNF aumentada de RFC 822, un valor de campo de encabezado de tipo de contenido se define de la siguiente manera:

 content := "Content-Type" ":" type "/" subtype
            *(";" parameter)
            ; Matching of media type and subtype
            ; is ALWAYS case-insensitive.

[...]

 parameter := attribute "=" value

 attribute := token
              ; Matching of attributes
              ; is ALWAYS case-insensitive.

 value := token / quoted-string

 token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
             or tspecials>

Bueno. Entonces parece que si quieres especificar un Content-Type encabezado con parámetros, simplemente hágalo así:

Content-Type: multipart/related; foo=bar; something=else

... y una versión doblada del mismo encabezado se vería así:

Content-Type: multipart/related;
    foo=bar;
    something=else

¿Correcto? Bien. Mientras seguía leyendo los RFC, me encontré con lo siguiente en RFC2387 Sección 5.1 (ejemplos):

 Content-Type: Multipart/Related; boundary=example-1
         start="<950120.aaCC@XIson.com>";
         type="Application/X-FixedRecord"
         start-info="-o ps"

 --example-1
 Content-Type: Application/X-FixedRecord
 Content-ID: <950120.aaCC@XIson.com>

 [data]
 --example-1
 Content-Type: Application/octet-stream
 Content-Description: The fixed length records
 Content-Transfer-Encoding: base64
 Content-ID: <950120.aaCB@XIson.com>

 [data]

 --example-1--

Hmm, esto es extraño. Ves el Content-Type ¿encabezamiento? Tiene varios parámetros, pero no todos tienen un ";" como delimitador de parámetros.

Tal vez simplemente no leí los RFC correctamente, pero si mi analizador funciona estrictamente como la especificación, el type y start-info Los parámetros darían como resultado una sola cadena o peor, un error de analizador.

Chicos, ¿qué piensas en esto? ¿Solo un error tipográfico en el RFCS? ¿O me perdí algo?

¡Gracias!

Answer 1

Es un error tipográfico en los ejemplos. Los parámetros siempre deben ser delimitados con semicolones correctamente, incluso cuando se doblan. El plegamiento no está destinado a cambiar la semántica de un encabezado, solo para permitir la legibilidad y tener en cuenta los sistemas que tienen restricciones de longitud de línea.

Answer 2

Posiblemente un error tipográfico, pero en general (y por experiencia) también debería poder manejar este tipo de cosas "en la naturaleza". En particular, los clientes de correo varían salvajemente En su capacidad para generar mensajes válidos y seguir todas las especificaciones relevantes (en todo caso, es aún peor en el mundo de correo electrónico/SMTP que el mundo www!)