[
https://issues.apache.org/jira/browse/MIME4J-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671418#action_12671418
]
Robert Burrell Donkin commented on MIME4J-112:
----------------------------------------------
"If the input message has been generated by mime4j then the round tripping
have to be bitwise identical."
is (for me) unlimited support for round tripping.
I think that it is an open question whether it is worthwhile Mime4J supporting
unlimited round tripping from meta-data. The best way to preserve a bitwise
identical message is to preserve the bits. (This is the approach suggested by
Jukka and Noel, and is the one that IMAP uses.) One of my personal goals for
Mime4J is to work on standard meta-data+document representations with
persistent storage (based on use cases in james). By preserving the original
bits, this approach would allow unlimited round tripping but at the cost of
additional memory usage.
A commitment to supporting unlimited round tripping (without preserving the
original bits) would require some tradeoffs in terms of code complexity and
performance. Here are a few examples:
1. Preservation of comment data after parsing fields
2. Preservation of information about character encoding in headers
3. Ability to build mail which does comply with the specifications
My feeling is that - given the availability of standard meta-data+document
representations - Mime4J should support only limited round tripping for mail
building representations.
> Define Limits Of Round Tripping In Mime4J
> -----------------------------------------
>
> Key: MIME4J-112
> URL: https://issues.apache.org/jira/browse/MIME4J-112
> Project: JAMES Mime4j
> Issue Type: Task
> Affects Versions: 0.6
> Reporter: Robert Burrell Donkin
> Fix For: 0.7
>
>
> By round tripping, I mean parsing some MIME document into a fully decomposed
> form and then recreating a new version of the document from this form.
> In theory, Mime4J decomposition and recomposition could be made perfect with
> no loss of information. In other words, given a MIME document, the parser
> could completely decompose the document and a bitwise identical copy could be
> recomposed.
> In practice, the limits of support are questionable. Some limitations may be
> expedient. For example, perhaps comments and encoding of ASCII characters are
> not sufficiently important to be worth preserving. Other limitations may
> arise from MIME documents which are not strictly compliant with the
> specification - for example, the use of unescaped non-ASCII characters in
> MIME headers may mean that the output would need to be escaped to ensure
> compliance.
> It is important to define and describe the limits of round tripping so that
> users and developers are clear about the level of support MIme4J claims. In
> addition, sufficient unit tests should be created to ensure in confidence
> that documents within these limits are correctly handled.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
