The IESG writes ("Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard "):
> The IESG has received a request from an individual submitter to consider the
> following document:
>
> - 'The APPLICATION/MBOX Media-Type '
> <draft-hall-mime-app-mbox-02.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2004-09-06.
I have the following comments:
* This specification is incomplete. There are unresolved issues
regarding the semantics of the format.
* Since mbox files are text files (assuming that any binary messages
in the mailbox are themselves encoded) and can be read sensibly
with the naked eye, the content type should be text/* not
application/*. This will also remove ambiguity surrounding line
endings.
* Since an mbox is actually an aggregate type - a way of encoding a
set of RFC822 messages - transfer encodings other than 7bit and
8bit should be discouraged. The spec should probably deprecate
them in most cases.
* The Proposed Standard should either include or refer to a specific
mbox format. The fact that there are variant implementations
doesn't mean that the Proposed Standard should hesitate to declare
those broken (at least, broken when a file is sent as text/mbox).
Those variant implementations are not wholly interoperable anyway,
and in order to write software which deals correctly with text/mbox
it will be necessary for the spec to say what the format is
supposed to be !
* The format specified should be that described in Rahu Dhesi's
posting to comp.mail.misc in 1996, <4ivk9s$bok@xxxxxxxxxxxxxxxx>.
* If an mbox file contains messages with unencoded binary data, the
file is difficult to sensibly process on a machine with non-UN*X
line-endings, because of the bare CRs in the binary data. (Bare
LFs are fine and look just like line endings, with From_-escaping
and all.) As far as I can tell there is then no non-lossy
representation of the file which allows sensible local processing
by non-mbox-specific tools. This issue should be resolved (or at
least acknowledged).
Ian.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf