Subject: [yam] Syntax of MIME documents (RFC 822 or 5322?)

From: Julien ÉLIE <[email-masked]>
Date: Sun, 10 Jan 2010 15:59:09 +0100

Hi,

Following a discussion on the USEFOR mailing-list:

    http://www.imc.org/ietf-usefor/mail-archive/msg04765.html
    http://www.imc.org/ietf-usefor/mail-archive/msg04766.html

we wonder why RFC 5322 mentions that the MIME document
series extends the syntax provided by RFC 5322 (Section 1.1):

   This document specifies a syntax only for text messages.  In
   particular, it makes no provision for the transmission of images,
   audio, or other sorts of structured data in electronic mail messages.
   There are several extensions published, such as the MIME document
   series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
   for the transmission of such data through electronic mail, either by
   extending the syntax provided here or by structuring such messages to
   conform to this syntax.  Those mechanisms are outside of the scope of
   this specification.

For instance, RFC 2045, which is based upon RFC 822, defines
(Section 5.1):

     parameter := attribute "=" value

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

     value := token / quoted-string

and RFC 822 has the following rule (Section 3.4.2):

        Note:  In structured field bodies, multiple linear space ASCII
               characters  (namely  HTABs  and  SPACEs) are treated as
               single spaces and may freely surround any  symbol.   In
               all header fields, the only place in which at least one
               LWSP-char is REQUIRED is at the beginning of  continua-
               tion lines in a folded field.

which is explicitly obsoleted by RFC 5322 (Section 4):

   Though these syntactic
   forms MUST NOT be generated according to the grammar in section 3,
   they MUST be accepted and parsed by a conformant receiver.

   One important difference between the obsolete (interpreting) and the
   current (generating) syntax is that in structured header field bodies
   (i.e., between the colon and the CRLF of any structured header
   field), white space characters, including folding white space, and
   comments could be freely inserted between any syntactic tokens.  This
   allowed many complex forms that have proven difficult for some
   implementations to parse.

Does it mean that a message that conforms to the syntax of RFC 5322
must not use a parameter like:

    posting-host = "posting.example.com:192.0.2.1"

and must use:

    posting-host="posting.example.com:192.0.2.1"

?

Have a nice week,

-- 
Julien ÉLIE

« Rubor, tumor, dolor, calor et functio laesa. »

---

From: Ned Freed <[email-masked]>
Date: Sun, 10 Jan 2010 11:37:05 -0800 (PST)

Of course it doesn't. RFCs 2045 and 2046 were written before DRUMS and RFCs
2821/2822/5321/5322 and therefore used the syntactic convensions of RFC 822,
where LWSP is implicitly allowed between tokens. The fact that DRUMS opted to
make the places where LWSP is allowed explicit rather than implicit doesn't
change the syntax rules for 2045 and 2046 in any way. shape or form.

I also note that had RFC 5322 had any effect on MIME syntax, the header of the
document would show that it updates RFCs 2045 and 2046. The document header
says no such thing.

				Ned

P.S. When revised MIME specifications come out they will probably switch to the
explicit LWSP approach since it seems that's the preferred way to do it now.

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 11 Jan 2010 22:56:26 +0100

Hi Ned,

> RFCs 2045 and 2046 were written before DRUMS and RFCs

OK, thanks a lot for having answered!

> explicit LWSP approach since it seems that's the preferred way to do it now.

Understood.  Thanks,

-- 
Julien ÉLIE

« Cela n'a rien de remarquable. Il suffit d'appuyer
  sur la bonne touche au bon moment et l'instrument
  joue tout seul. » (J.-S. Bach)