On Mon, 24 Nov 2003, Timo Sirainen wrote: > > > Well, one possibly useful field would be References header in > > > message/rfc822 body parts. > > That's not a BODYSTRUCTURE issue; it is an ENVELOPE issue. > FETCH ENVELOPE can be easily worked around with FETCH[HEADER.FIELDS > (whatever you want)].
Yes, and for References, that is what you do to work around it. References is properly an ENVELOPE field, not a BODYSTRUCTURE field. > Fetching more headers for message/rfc822 body > parts isn't possible without a BODY/BODYSTRUCTURE first and then sending > a separate FETCH BODY.PEEK[n.HEADER.FIELDS (more)] request for each body > part. What is why BODYSTRUCTURE is extensible, and why it has been extended to accomodate the current set of MIME headers. It is believed that that set is naturally bounded and will not be subject to the type of growth that will affect message headers. This is by design. Ideally, Content-Type and Content-Transfer-Encoding would have been the only MIME headers. This resolve has been somewhat undermined, but it remains. > What if the fields returned in ENVELOPE (and embedded ENVELOPEs in > BODYSTRUCTURE) were configurable by client for the current session? The problems with that are that it makes an already complex protocol even more complex, and it greatly expands the number of failure cases. An extensible ENVELOPE that incorporates the obvious missing fields (e.g. References) and reforms address lists would be a good thing. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
