This is a formal objection to the Last Call of
draft-ietf-eai-utf8headers-09.txt [EAI-utf8header].
Insofar as fixing the problem I shall describe would have repercussions in
draft-ietf-eai-smtpext-11.txt [EAI-SMTP-extension] and in
draft-ietf-eai-dsn-06.txt [EAI-dsn]
(especially the latter), it should be construed as a formal objection to
those as well.
Essentially, my concern is that a new MIME subtype message/global is
defined, and that this new message subtype is in breach of RFC2045, which
currently has the status of Draft Standard.
Introduction and Terminology
----------------------------
[EAI-utf8header] describes, for Experimental use, a new class of Internet
Email Messages, which we may term "Global Messages" which it is hoped will,
in the long term, become a replacement for the messages defined in RFC2822
(plus the MIME standards RFC 204[56]), and which we may term "Current
Messages".
Global Messages are a superset of Current Messages, defined by adding extra
features (notably the use of UTF-8 within headers) by way of extensions to
RFC 2822 and RFC204[56], plus associated extensions to RFC2821 in
[EAI-SMTP-extension]. They are intended to be created, transported and read
by suitably augmented MTAs and MUAs which will advertise the capability
"UTF8SMTP". Whenever a Global Message is offered to an agent which does not
support UTF8SMTP, it MUST either be rejected, or alternatively "downgraded"
to become a valid Current Message capable of being transported over the
"Curent Network" of installed MTAs (possibly being upgraded after final
delivery).
I have no problem with defining extensions to RFC 2822 and even to
RFC204[56] (e.g. to permit UTF-8 in places where those current documents do
not allow it). However, this proposal goes beyond that by introducing
objects that are intended to be transported over the Current Network in a
manner at variance with RFC2045.
Message/global
--------------
[EAI-utf8header] states, in Section 1.2:
This document updates section 6.4 of RFC 2045. It removes the
blanket ban on applying a content-transfer-encoding to all subtypes
of message/, and instead specifies that a composite subtype MAY
specify whether or not a content-transfer-encoding can be used for
that subtype, with "cannot be used" as the default.
This document also updates [RFC2822] and MIME, and the fact that an
experimental specification updates a standards-track spec means that
people who participate in the experiment have to consider those
standards updated.
Allowing of use a content-transfer-encoding on subtypes of messages
is not limited to transmissions, which are authorized by the SMTP
extension specified in [EAI-SMTP-extension]. Message/global permits
use of a content-transfer-encoding.
The third paragraph of that explicitly seeks to permit the extension
specified in the first paragraph to be used in messages handled by agents
which do not support UTF8SMTP as defined in [EAI-SMTP-extension].
More specifically, Section 4.6 describes the new MIME subtype message/global
which is intended to encapsulate Global Messages in the same way that
message/rfc822 is intended to encapsulate Current Messages. The Template for
this new MIME subtype includes the words:
Encoding considerations: Any content-transfer-encoding is permitted.
The 8-bit or binary content-transfer-encodings are recommended
where permitted.
And furthermore it is claimed that, even without downgrading, this new MIME
subtype will interoperate with the installed base:
Interoperability considerations: The media type provides
functionality similar to the message/rfc822 content type for email
messages with international email headers. When there is a need
to embed or return such content in another message, there is
generally an option to use this media type and leave the content
unchanged or downconvert the content to message/rfc822. Both of
these choices will interoperate with the installed base, but with
different properties. Systems unaware of international headers
will typically treat a message/global body part as an unknown
attachment, while they will understand the structure of a message/
rfc822. However, systems which understand message/global will
provide functionality superior to the result of a down-conversion
to message/rfc822. The most interoperable choice depends on the
deployed software.
Now message/global needs to be able to pass unscathed through a chain of
agents such as the following:
A B C D
Global MTA ----> Current MTA ----> Current MTA ----> Current MUA
supporting supporting not supporting
both UTF8SMTP 8BITMIME 8BITMIME
and 8BITMIME
and [EAI-utf8header] proposes to allow A to pass a message/global to B
as-is, in the expectation that B will then apply a Content-Transfer-Encoding
such as Quoted-Printable or Base64 before passing it to C, which would then
be decoded by D.
The problem
-----------
However, RFC2045, with which B and C as part of the "installed base" are
supposed to comply, contains the following (Section 6.4):
Certain Content-Transfer-Encoding values may only be used on certain
media types. In particular, it is EXPRESSLY FORBIDDEN to use any
encodings other than "7bit", "8bit", or "binary" with any composite
media type, i.e. one that recursively includes other Content-Type
fields. Currently the only composite media types are "multipart" and
"message". All encodings that are desired for bodies of type
multipart or message must be done at the innermost level, by encoding
the actual body that needs to be encoded.
The Encoding Consideration quoted above, which allows B to apply that
Encoding, is therefore in direct violation of that "EXPRESSLY FORBIDDEN".
Now I might well agree that that restriction is unfortunate and misguided,
and even that it ought to be changed. But RFC2045 is a Draft Standard, and
it is entirely outside the remit of the EAI WG to attempt to change what is
in a Draft Standard.
Section 5.2.4 of RFC2046 (which is also a Draft Standard) contains the
following:
MIME implementations must in general treat unrecognized subtypes of
"message" as being equivalent to "application/octet-stream".
Future subtypes of "message" intended for use with email should be
restricted to "7bit" encoding. A type other than "message" should be
used if restriction to "7bit" is not possible.
and on that basis it is argued in [EAI-utf8header] (4.6) that existing
software such as B or C would therefore treat the unrecognized message
global as an "application/octet-stream" and therefore generate (C) or accept
(D) Quoted-Printable or Base64 accordingly. However, the second paragraph
quoted above makes it clear that the encoding of any future message subtype
should be "7bit", thus supporting that "EXPRESSLY FORBIDDEN". Moreover,
RFC2046 Section 4.5.1 discourages any further processing of an
application/octet-stream:
The recommended action for an implementation that receives an
"application/octet-stream" entity is to simply offer to put the data
in a file, with any Content-Transfer-Encoding undone, or perhaps to
use it as input to a user-specified process.
Furthermore, if the interpretation of RFC2046 Section 5.2.4 suggested in
[EAI-utf8header] is correct, it follows that RFC2046 is inconsistent with
RFC2045. Inconsistency between two Draft Standards is a serious matter, but
one which is to be resolved by the IESG rather than by an individual WG
such as EAI.
Consequences for the Installed Base
-----------------------------------
Now I might have been persuaded that this violation of existing standards
should be allowed to pass if it were the case that the "installed base" had
already taken that particular interpretation and was already setup, when
asked to pass an unknown message subtype to an agent which did not advertise
8BITMIME, to encode it in the manner that would have been appropriate for an
application/octet-stream. But such is patently not the case.
It has been established, for example, that none of Sendmail, Exim or Qmail
take that approach, and between them these three account for a very
substantial part of the installed base. Sendmail, in particular, takes great
pains to follow the current standards as written. I asked repeatedly on the
WG for examples of current implementations that would behave in the manner
expected, but was told of only one (M-Switch, by Isode, which is used by
only a fraction of current sites), and it was not even certain whether even
that one would do so.
It can only be concluded, therefore, that the current installed base is
unsuited to handle the new message/global in the manner envisaged.
What to do about it?
--------------------
My proposed solution to the problem would be to declare an extension
allowing Global Messages to be encapsulated within the present
message/rfc822 subtype , but only when passed between agents supporting these
extensions, and for it to be downgraded to an unextended message/rfc822
before passing into the Current Network. This would require a recursive
downgrading of all the Global objects within it, but current agents already
do something similar (or are supposed to do so) when passing messages to
non-8BITMIME systems, and so they already contain the necessary basic
framework for that purpose.
It should be noted that [EAI-dsn] requires this problem to be adequately
solved, since DSNs regularly include the full message which is the subject
of the Notification, and even when this is a Global Message the DSN may
still need to pass through (perhaps several) Current MTAs. [EAI-dsn]
currently proposes to use the new message/global for this purpose, but this
simply will not work for the reasons given.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@xxxxxxxxxxxxxxxx Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf