[yam] Syntax of MIME documents (RFC 822 or 5322?)
Julien ÉLIE <julien@trigofacile.com> Sun, 10 January 2010 17:45 UTC
Return-Path: <julien@trigofacile.com>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0753A6912 for <yam@core3.amsl.com>; Sun, 10 Jan 2010 09:45:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.993
X-Spam-Level:
X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jcm3D5iAx3zY for <yam@core3.amsl.com>; Sun, 10 Jan 2010 09:45:49 -0800 (PST)
Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by core3.amsl.com (Postfix) with SMTP id 9912A3A6929 for <yam@ietf.org>; Sun, 10 Jan 2010 09:45:48 -0800 (PST)
Received: (qmail 28335 invoked by uid 503); 10 Jan 2010 16:04:26 -0000
Received: from b6.ovh.net (HELO mail93.ha.ovh.net) (213.186.33.56) by 27.mail-out.ovh.net with SMTP; 10 Jan 2010 16:04:25 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 10 Jan 2010 14:59:08 -0000
Received: from aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr (HELO Iulius) (julien%trigofacile.com@83.114.7.94) by ns0.ovh.net with SMTP; 10 Jan 2010 14:59:07 -0000
Message-ID: <B7A4317EB74542058E6657F472CC5396@Iulius>
From: Julien ÉLIE <julien@trigofacile.com>
To: yam@ietf.org
Date: Sun, 10 Jan 2010 15:59:09 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="ISO-8859-15"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 16950141623657299270
X-Ovh-Remote: 83.114.7.94 (aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
X-Mailman-Approved-At: Sun, 10 Jan 2010 09:51:28 -0800
Subject: [yam] Syntax of MIME documents (RFC 822 or 5322?)
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Jan 2010 17:45:50 -0000
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. »