I do not have a use for telling someone their message is non-compliant. I have a use for parsing emails. I'm a simpleton user though, so can only speak to my own needs.
-- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] On Mon, Jul 21, 2008 at 8:01 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > I opened this issue a week ago: > http://issues.apache.org/jira/browse/MIME4J-54 > > Given the recent discussions about strict parsing and my view of the RFC > compliance vs real world use case, before spending time in trying to fix > this I would like to know if there is any harm in fixing this. > > Please speak now or I'll go on with fixing that issue with no configurable > behaviour: so only boundaries at the beginning of a line will be parsed. > > > I would also like to collect opinions about the handling of chars at the end > of the boundary. > From the RFC it's clear we have to deal with padding at the end of the > boundary, but this sentence leave me doubts about what we have to expect > there (from http://www.faqs.org/rfcs/rfc2046.html): > ================================== > NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the > boundary value with the beginning of each candidate line. An exact > match of the entire candidate line is not required; it is sufficient > that the boundary appear in its entirety following the CRLF. > ===================================== > Do you think this is only about *ending* boundary or *any* boundary? > > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
