On Oct 22, 2003, at 2:33 PM, Guy Harris wrote:
On Oct 22, 2003, at 4:52 AM, Yaniv Kaul wrote:
2. Big patch for packet-oxid.c, that is accompanied by a helper file - packet-dcerpc-dcom.c (which will also be used in future patches that I'll send regarding other DCOM interfaces).
...and another helper file, packet-dcerpc-dcom.h.
However, "packet-dcerpc-dcom.h" isn't used, and "packet-dcerpc-dcom.c" is included by "packet-dcerpc-oxid.c". Curently (as of 1.8), "packet-dcerpc-oxid.c" includes "packet-dcerpc-dcom.h"; is that what *should* be included, with "packet-dcerpc-dcom.c" being compiled as a separate source file?
(Also, for some reason, all the files attached to your message had "Content-Disposition: inline"; that meant that my mail reader at work (Mac OS X Mail.app) showed them, well, inline, rather than as attachments, as per RFC 2183:
2.1 The Inline Disposition Type
A bodypart should be marked `inline' if it is intended to be
displayed automatically upon display of the message. Inline
bodyparts should be presented in the order in which they occur,
subject to the normal semantics of multipart messages.and, unfortunately, didn't have a way to let me extract them.
If you can make them show up as attachments, with "Content-Disposition: attachment":
2.2 The Attachment Disposition Type
Bodyparts can be designated `attachment' to indicate that they are
separate from the main body of the mail message, and that their
display should not be automatic, but contingent upon some further
action of the user. The MUA might instead present the user of a
bitmap terminal with an iconic representation of the attachments, or,
on character terminals, with a list of attachments from which the
user could select for viewing or storage.
that'd make it easier to extract them.)
