I cannot speak for Neil, but this is the first I've seen of any new BNF. Maybe
I lost a message or something... Anyway, I was responding to your statement:
" ... I believe most implementations accept one or two CRLF's before the part,
so interoperability isn't at stake. It sure seems to be cleaner with just one
CRLF, though. ... "
I agree that the BNF you posted in your second message puts two CRLFs before
the boundary when encapsulating normal text. More specifically, here's the BNF
you posted:
preamble := optional-text
epilogue := optional-text
optional-text := *(text CRLF)
close-delimiter := "--" boundary "--" CRLF
delimiter := "--" boundary CRLF
encapsulation := delimiter body-part CRLF
multipart-body := preamble 1*encapsulation close-delimiter epilogue
And here's the BNF from RFC1341:
preamble := *text
epilogue := *text
close-delimiter := CRLF "--" boundary "--"
delimiter := CRLF "--" boundary
encapsulation := delimiter CRLF body-part
multipart-body := preamble 1*encapsulation close-delimiter epilogue
This is one of those cases where all the referencing clouds the issue
rather than revealing it. If you expand the BNF you posted you get:
multipart-body := *(text CRLF) 1*("--" boundary CRLF body-part CRLF)
"--" boundary "--" CRLF *[text CRLF]
And the BNF from RFC1341 gives you:
multipart-body := *text 1*(CRLF "--" boundary CRLF body-part)
CRLF "--" boundary "--" epilogue
All this has the effect of getting rid of the leading CRLF as well as insuring
that the closing boundary line ends with a CRLF. I find the new definitions of
delimiter and close-delimiter to be rather awkward, but other than that this
new BNF seems to be a slight improvement over what we have now.
The fact remains, however, that each encapsulation involves two CRLFs using
either BNF and any existing transport, and this does not gibe with the
statement you made previously.
Ned