Noel J. Bergman wrote:
Do you want to post some revised JAMES code to demonstrate the features?
Anything in particular you had in mind? I have to admit I hardly know
the JAMES codebase at all.
The header parser is also missing the ability to parse trace
(i.e. return-path, received) and message-id fields.
Both Stream and DOM, or just the latter?
Both--they use the same header parser(s). When I say "missing the
ability to parse", I mean, you can ask for the header value, but other
than whitespace unfolding, we don't do any transforming of the field data.
Actually, I've been a little uneasy about implementing these two
parsers, maybe some people on this list can shed some light on these
questions.
* Is it useful/desirable to parse the message-id field (into left and
right parts)? I get the impression that a relatively high number of
mail messages have syntactically illegal message-id values--two @ signs
seems to be a particularly common offense. Since the message-id is
really intended to be used as an opaque value, wouldn't it be more
robust and equally useful for the parser to treat it as such?
* Is it useful/desirable to parse the Received field into name/value
pairs? If so, anyone on this list have a lot of experience with
real-world Received values? It looks to me like there are a lot of
illegal Received headers out there, as well as a lot of useful
information stuck in parenthetical comments. In fact, according to Dan
Bernstein, "It is probably best for readers to treat everything before
the final semicolon as unstructured text, purely for human consumption."
(http://cr.yp.to/immhf/envelope.html) Agree/disagree?
-jmc
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
