[
https://issues.apache.org/jira/browse/MIME4J-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671462#action_12671462
]
Stefano Bagnara commented on MIME4J-112:
----------------------------------------
@Robert: I guess my explanation was not clear, because your concern are not
valid in my "requirement".
"1. Preservation of comment data after parsing fields"
Does mime4j write comments in output? if so then it must be able to parse them.
if it parses a comment written by itself and then write again it to output how
can this be different from the previous one? Can you make an example? (i mean,
if mime4j loses comments, then they will be loose at the first pass and we can
ignore them for my "internal roundtrippin" requirement.
"2. Preservation of information about character encoding in headers"
Again, if mime4j alters the encoding during the write I would expect it to
always use the same encoding in the same scenario. What would break my
requirement is something like an "alternate" behaviour: let's say mime4j
convert qp in base64 and base64 in qp at every parse=>writeout execution this
would result in a A->B->A->B->A->B behaviour and this would be unacceptable.
but A->B->B->B and B->A->A->A->A are both acceptable to me.
"3. Ability to build mail which does comply with the specifications"
Compliance is important, but it is unrelated to roundtripping, IMO.
I would expect mime4j to write compliant message in output and to be able to
parse them. In any case mime4j is writing a malformed message in output I want
it to be able to parse it again and a subsequent write to stream should result
in the same malformed message.
> 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.
