[Fwd: I-D ACTION:draft-hall-mime-app-mbox-03.txt]
blilly at erols.com
Sun Jan 30 17:24:13 CET 2005
On Wed January 26 2005 14:57, Eric A. Hall wrote:
> The ADs for the applications area are going to move this into last-call
> again, but we all want to run it back up the flagpole one more time.
> This version departs from earlier releases by specifying a "format"
> parameter to the application/mbox media-type, by defining a "default"
> value for the parameter,
Several things are missing related to that:
1. A registration procedure for registering new format value keywords
(that could be, and probably should be, a separate document).
2. An IANA Considerations section related to establishment of a
format value keyword registry (containing the "default" entry),
and maintenance of that registry in conjunction with the
3. Location of the format value keyword registry (so that implementors
can find the registry). That should be coordinated with IANA.
4. Syntax rules and ABNF for the format keyword values, unless
5. Semantic rules for format value keywords, e.g. are they
6. Provision, if any, for private-use or experimental format value
keywords (e.g. reservation of keywords beginning with"x-" for
> The "default" format uses a sequence of 822 messages, with the exception
> that line-endings are LF instead of CR/LF (this only applies to the
> canonical database, and doesn't affect the transfer protocol or anything
> Another thing that is specified here is that separator lines (at the
> least) must be encoded to prevent local collisions, when an mbox
> attachment is saved into an existing local folder (messages can become
> irreversible mingled if some kind of escaping is not performed).
Since the format differs from canonical message format, and as there
appears to be provision for encoding parts of the media type (using
an unspecified encoding algorithm), it appears that several items are
missing regarding such encoding:
1. encoding algorithm(s) and corresponding decoding algorithm(s)
2. how the particular encoding algorithm used by the originator is
specified with the media type so that it can be reversed by the
3. interaction between any transfer encoding (RFC 2045) which may
be present in messages and the encoding algorithms above
4. if it is possible to have the entire media type encoded or
only portions ("at the least") encoded, how the recipient can
determine which is the case, and how to identify which portions
are encoded so that appropriate decoding -- of those portions
only -- can be performed w/o mangling unencoded portions, even
if those unencoded portions contain content which has octet
sequences resembling encoded portions. [I suspect that partial
encoding won't work, and that the entire media type would have
to be encoded/decoded as a unit.]
5. Interaction of encoding mechanisms and modifications that may
occur during transport (message/partial fragmentation, addition
of spurious whitespace, removal of trailing whitespace, etc.).
6. Since the media type format contains lone LF octets, it is
unsuitable for transfer w/o transfer encoding (RFC 2822 section
2.3); it is therefore possible that:
a) a message within an mbox may have had RFC 2045 transfer
encoding applied to a body MIME-part, with a corresponding
b) CRLF sequences delimiting lines may have been changed to LF
c) some encoding may be applied to all or portions of the media
type for the purpose of escaping "separator lines"
d) transfer encoding may have to be applied to the media type
for transfer, as it would otherwise contain non-conforming
octet sequences (LF not immediately preceded by CR (RFC 2822
In order to recover content end-to-end, it is necessary to
specify the order of the various transformations and the
corresponding decoding sequence, to prevent undesirable
interaction between encoding/decoding operations that would
alter message content.
In the registration temple, the magic number could be indicated as
0x46726F6D20 ("From ").
More information about the Ietf-types