I have created an agent to convert the Notes mail document into DXL format using the NotesDXLExporter in a Domino 6.5.1 server following the examples given in the help.nsf.
The DXL conversion works wonderfully if the mail document is received from Notes client. All Notes elements are converted properly and I can extract their value using standard XML techniques.
However, if the mail document comes from Internet (probably in MIME format), the conversion will run into problem. All converted Notes elements (i.e. “dxl:item”) will contain a child element , the value of which is in something like the hex64 format that is NOT directly readable. This creates big problem to my extraction program.
I don’t why the NotesDXLExporter behaves in such strange way.
Do any of you have some advice for me? Thanks.
Subject: not yet specifically represented in DXL; here’s how you track down what the data really is (though not easily)
DXL does not yet represent all possible Notes data types as their own element. For those that are not otherwise represented in DXL, DXL emits their raw data within an element as Base64 data. Base64 is a simple encoding where any data can be represented in a character set of 64 printable ASCII characters. Basically, every 3 bytes of source data are split into 4 6-bit “bytes” and then mapped to one of the 64 characters. The algorithm to decode Base64 is simple and I would assume readily available on the Web.
Once you decode the Base64, what you basically have is what you would have at the C API level. If you look at the header files in a C API Toolkit, you can figure out what the data is.
In this case, nsfdata.h will tell you that maps to TYPE_RFC822_TEXT:
#define CLASS_TEXT (5 << 8)
#define TYPE_RFC822_TEXT 2 + CLASS_TEXT /* RFC822( RFC2047) message header; Canonical form */
From there, it is probably easiest to use the C API Reference Manual, which will lead you to this type defined in mimeods.h which defines the data stored in this type:
typedef struct {
WORD wVersion; /* ODSSizeof this structure for versioning */
DWORD dwFlags; /* TYPE_822_TEXT flags. The first three bits
are reserved for the format mask, the formats
defined include: */
#define RFC822_ITEM_FORMAT_MASK 0x00000007
#define RFC822_ITEM_FORMAT_ADDR 0x00000000 /* 822-header is an address */
#define RFC822_ITEM_FORMAT_DATE 0x00000001 /* 822-header is a date */
#define RFC822_ITEM_FORMAT_TEXT 0x00000002 /* 822-header is text */
/* the remaining
bits are flags which include: */
#define RFC822_ITEM_STORAGE_STRICT 0x00000008 /* STRICT storage format */
#define RFC822_ITEM_TEXT_LIST 0x00000010 /* Text item is TEXT_LIST */
#define RFC822_TEXT_UNUSED 0x00000020 /* First available flag */
WORD wNotesNativeLen; /* Length of the Notes version which is either
a LMBCS string or a TIMEDATE. */
WORD w822NameLen; /* Length of the original 822 header name */
WORD w822DelimLen; /* Length of the original 822 header delimiter */
WORD w822BodyLen; /* Length of the original 822 header body in
it's native charset and encoding (RFC2047) */
} RFC822ITEMDESC;
We plan on adding specific DXL tags for MIME data types in a 7.x maintenance or point release.