james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin (JIRA)" <mime4j-...@james.apache.org>
Subject [jira] Commented: (MIME4J-112) Define Limits Of Round Tripping In Mime4J
Date Sat, 07 Feb 2009 07:48:59 GMT

    [ 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.


Mime
View raw message