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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf