Re: Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard

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@ietf.org or ietf@ietf.org 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@hustle.rahul.net>.

 * 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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf