[
https://issues.apache.org/jira/browse/MIME4J-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118453#comment-13118453
]
Stefano Bagnara commented on MIME4J-203:
----------------------------------------
@Jostya: I read it twice. No way it says the tab belongs to the field name and
not to the body or that the tab is to be collapsed to the separator (the ":").
So it still belongs to the body. Then when you evaluate the body you follow
that rule (also the rule says they have to be collapsed to a single space, not
ignored, nor removed). Last thing: it is better to check latest RFC as RFC822
is obsolete. RFC5322 says:
------
3.6.1. The Origination Date Field
The origination date field consists of the field name "Date" followed
by a date-time specification.
orig-date = "Date:" date-time CRLF
------
You see everything after "Date:" is a date-time token for the grammar. And the
date-time token is defined as I previously quoted (may start with FWS).
The obsolete rfc822 also allows spaces between "Date" and the ":" (, but BEFORE
the ":").
------
4.5.1. Obsolete Origination Date Field
obs-orig-date = "Date" *WSP ":" date-time CRLF
------
Everything after the ":" belong to the body and I still can't find any sentence
in the rfc alluding to something else.
@Oleg: Yes, I agree that they should be consistent (I simply said I didn't
agree with the analysis of the rfc pointer provided). My main point is that the
date header body parser should correctly accept initial FWS as the
specification says it have to. I remember the main cause I left that space
handling in RawField during last refactoring is because removing that we
produced mimemessages that was uncommon because setting most header would
result in "headename:headervalue" with no space, while the most common mime
format found out there have a space and I believe some processing tool even
doesn't happily accept an header without spaces after the ":" (it is almost a
de fact standard): maybe we discussed this in the list, I don't remember right
now, sorry.
> RawField parsing problem in case of '\t' delimiter
> --------------------------------------------------
>
> Key: MIME4J-203
> URL: https://issues.apache.org/jira/browse/MIME4J-203
> Project: JAMES Mime4j
> Issue Type: Bug
> Components: dom
> Affects Versions: 0.7
> Environment: linux 3.0.1, x86_64
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
> Reporter: Kostya Gribov
> Fix For: 0.7.1
>
> Attachments: patch
>
>
> RawField doesn't drop '\t' char between field header and body, so body starts
> from LWSP-char that should be ignored by RFC822 (see 3.4.2 in spec) because
> date field is structured. So date isn't extracted.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
