A while ago, Chris Newman wrote:
Let's not repeat the mistakes of the past. If there's only one format,
there's only one way to do a parser which seems to work, and it will work
with everything. If there's multiple formats, there's multiple ways to do
a parser which seems to work, and so it won't work with everything.
This runs into _big_ problems for users who want to edit their sieves
by simply dropping them into a text editor on the machine the sieve will
run on perhaps their UNIX box, or, as in my case, my Risc PC. I admit this
objection may not be valid for users who are storing their sieves with ACAP
or something, but these will be in a minority to start with. It is not
viable to rely on people being able to edit files with your chosen line
terminator easily on a given system.
Whatever the decision, I _will_ accept LF as a line terminator in my
implementation, even if I immediately deprecate this... It will be
sufficiently useful to me and my alpha test group that it would be
stupid not to accept this.
If we specify that the line terminator is CR|CRLF|LF (any of these
acceptable) then there will NOT be a compatibility problem. _All_
compliant implementations MUST accept all three.
Regarding the PostScript case, I doubt we'll see binary inlined into
sieves. The only place it is meaningful is in an autoreply, and it
probably ought to be BASE64-encoded there anyway. To be quite honest,
I hope I don't live to see the day when people add binary attachments
to autoreply messages anyway...
Thomas
--
Interalia design - purveyors of fine mailers since 1998 (maybe)