[Guy Harris <guy@xxxxxxxxxxxx>]

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.)