james-mime4j-dev mailing list archives

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

    [ 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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message