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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf