Re: tbird AND javamail both broken
On Wed 30 Nov 2022 at 23:02:16 (+0000), Gareth Evans wrote:
> On Tue 29 Nov 2022, at 16:52, David Wright <deblis@lionunicorn.co.uk> wrote:
> > Yes, but my post responded to, and only concerned, what lies between
> > the end of the body area and the next boundary marker, whereas your
> > quotation here from RFC1521 (which I haven't consulted) is about the
> > beginning of the body area and any header preceding it.
>
> Sorry, the point I was getting at didn't quite emerge!
>
> I meant the fact that there are blank lines in the example
>
> https://www.rfc-editor.org/rfc/rfc2049#page-15
>
> before each boundary, as well as after all of the part field headers, it being a conformance example, initially suggested requirement to me. But I now realise that the example's blank lines before the part boundaries are there for readability purposes, and form part of the sections including the text preceding them. So the example leaves that at least for the reader to interpret correctly.
>
> I discovered last night that the BNF for the formal definitions, which you have to string together to generate a blank line from concatenating CRLFs, appears in RFC 2046. This isn't named or linked to in 2049's Abstract, as the other docs in the latest MIME "set" are. I was skimming a bit and didn't see the other references to it.
You're right—an editorial lapse.
> That quote was from 1521:
>
> >> RFC1521, obsoleted by 2049, includes:
> >> " 7.2 ... Each part ..."
>
> - whereas afaics, 2049 only offers the note in Appendix A, from which the necessity for a blank line following part headers can be deduced, but you have to think about it, and know that it needs to be thought about. I thought the idea of RFCs was at least partly to explain things as well as specify. If so, I don't think RFC2049 does this as well as 1521.
I think we're in agreement that everything is /defined/ in this
set of RFCs. As for lengthy explanations, I think you have to
bear in mind that the earlier RFCs often introduced concepts and
material that were quite new at the time, whereas later ones
might have been written when it could be assumed readers were
more familiar with the matter, and it could be presented in
a more cut and dried manner. Otherwise an evolutionary sequence
of RFCs would grow even faster than they currently do.
(This set is already 50% longer than RFC1521/2 that it supersedes.)
Cheers,
David.
Reply to: