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

On 8/17/2004 4:06 PM, John C Klensin wrote:

> In that context, unless I completely misunderstand what is going
> on here, the "...prerequisite to having a half-baked parser..."
> assertion borders on the silly.   Take the example to which Tony
> has been pointing.  Apparently the Solaris version of an mbox
> format is well-documented and based on content length
> information rather than key strings.

... it is well-defined for writing, but AFAIK the number of reliable
clients that depend on the presence of such data are zero.

This is the point really: Given that the database structure really is
undefined, and that any number of clients may have accessed the database
via ~NFS or via different mailers on the same local client (Pine and KMail
and ...), a half-baked mailer that wants to reliably read mbox data of any
kind will know better than to rely on Content-Length in isolation, and
will have to validate assumptions and check the clues before doing
anything substantive. This includes checking for EOL syntaxes, but also
includes things like default charsets for untagged data, default domains,
and so forth.

> Given that model, the key to an mbox format isn't the content of
> the blobs, it is the system used to decompose an mbox into a
> blob collection.

That's a function of the content parser and whatever task it is trying to
perform. The purpose of importing an mbox database into an IMAP store (as
is common with things like downloadable archives) is going to have several
different considerations and requirements than simple searching and
printing (as with local archives generated by ~Mozilla locally), but both
of them can be satisfied through basic sniff tests and local defaults.

Most of the spec work is appropriate and useful and arguably necessary for
*writing* to mbox files, especially if you are appending an existing file,
but even then it takes few smarts to figure out that you should write to
the existing content instead of druidic rules. Having said that, I'd love
to see a canonical authoritative format which could be referenced for such
purposes (not for transfers, but for parsers to use when they go about
generating content).

> Instead, you are making a case that this registration should be
> a family of, e.g.,
>   application/mbox-solaris-v5-and-later
>   application/mbox-sendmail-v2-v4

I hope not; unrecognized types match to application/octet-stream so many
types that nobody implements won't get us very far either.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf