<html>
<head>
<title>OpenChange Property Files 0.8 API Documentation</title>
<link href="doxygen.css" rel="stylesheet" type="text/css"/>
<link href="apidocs.css" rel="stylesheet" type="text/css"/>
</head>
<body>
<div id="website">
<div class="header"></div>
<div id="middle_side">
<div id="right_side_home">
<!-- Generated by Doxygen 1.5.9 -->
<div class="navigation" id="top">
<div class="tabs">
<ul>
<li class="current"><a href="index.html"><span>Main Page</span></a></li>
<li><a href="files.html"><span>Files</span></a></li>
<li><a href="examples.html"><span>Examples</span></a></li>
</ul>
</div>
</div>
<div class="contents">
<h1>OpenChange Property File (OCPF)</h1>
<p>
<h3 align="center">0.8 </h3><h2><a class="anchor" name="ocpf">
OpenChange Property File (OCPF)</a></h2>
<h2><a class="anchor" name="Contents">
Contents</a></h2>
<ul>
<li>
<a href="#revision">Revision History </a> </li>
<li>
<a href="#introduction">1. Introduction </a> </li>
<li>
<a href="#purpose">2. Purpose and Scope </a> </li>
<li>
<a href="#limit">3. Limitations and Bugs </a> </li>
<li>
<a href="#syntax">4. Syntax </a> </li>
<li>
<a href="#keywords">5. Top Level Keywords </a> <ul>
<li>
<a href="#type">5.1. TYPE </a> </li>
<li>
<a href="#folder">5.2. FOLDER </a> </li>
<li>
<a href="#set">5.3. SET </a> </li>
<li>
<a href="#oleguid">5.4. OLEGUID </a> </li>
<li>
<a href="#recipient">5.5. RECIPIENT </a> </li>
<li>
<a href="#property">5.6. PROPERTY section </a> </li>
<li>
<a href="#nproperty">5.7. NPROPERTY section </a> </li>
</ul>
</li>
<li>
<a href="#properties">6. Known Properties </a> <ul>
<li>
<a href="#propname">6.1. Property Name </a> </li>
<li>
<a href="#proptag">6.2. Property Tag </a> </li>
</ul>
</li>
<li>
<a href="#nproperties">7. Named Properties </a> <ul>
<li>
<a href="#OOM">7.1. OOM </a> </li>
<li>
<a href="#MNID_ID">7.2. MNID_ID </a> </li>
<li>
<a href="#MNID_STRING">7.3. MNID_STRING </a> </li>
</ul>
</li>
<li>
<a href="#proptype">8. Supported Property Types </a> <ul>
<li>
<a href="#boolean">8.1. PT_BOOLEAN </a> </li>
<li>
<a href="#short">8.2. PT_SHORT </a> </li>
<li>
<a href="#long">8.3. PT_LONG </a> </li>
<li>
<a href="#double">8.4. PT_I8 </a> </li>
<li>
<a href="#string8">8.5. PT_STRING8 </a> </li>
<li>
<a href="#unicode">8.6. PT_UNICODE </a> </li>
<li>
<a href="#systime">8.7. PT_SYSTIME </a> </li>
<li>
<a href="#mv_string8">8.8. PT_MV_STRING8 </a> </li>
<li>
<a href="#binary">8.9. PT_BINARY </a> </li>
</ul>
</li>
<li>
<a href="#comments">9. Comments </a> </li>
<li>
<a href="#tools">10. OCPF and openchangeclient </a> <ul>
<li>
<a href="#syntax">10.1. ocpf_syntax </a> </li>
<li>
<a href="#sender">10.2. ocpf_sender </a> </li>
<li>
<a href="#dump">10.3 ocpf_dump </a> </li>
</ul>
</li>
</ul>
<br>
<p>
<a class="anchor" name="revision"></a><h2>Revision History</h2>
<p>
<table align="center" width="80%" border="1" cellspacing="3" cellpadding="3">
<tr>
<td style="text-align:center"><b>Date</b> </td><td style="text-align:center"><b>Revision Number</b> </td><td style="text-align:center"><b>Author</b> </td><td style="text-align:center"><b>Revision Content</b> </td></tr>
<tr>
<td style="text-align:center">01/04/08 </td><td style="text-align:center"><b>0.5</b> </td><td style="text-align:center">Julien Kerihuel </td><td style="text-align:center">Add RECIPIENT support </td></tr>
<tr>
<td style="text-align:center">29/03/08 </td><td style="text-align:center"><b>0.4</b> </td><td style="text-align:center">Julien Kerihuel </td><td style="text-align:center">Add PT_UNICODE support and ocpf_dump option </td></tr>
<tr>
<td style="text-align:center">06/03/08 </td><td style="text-align:center"><b>0.3</b> </td><td style="text-align:center">Julien Kerihuel </td><td style="text-align:center">Add PT_BINARY and Streams support </td></tr>
<tr>
<td style="text-align:center">05/03/08 </td><td style="text-align:center"><b>0.2</b> </td><td style="text-align:center">Julien Kerihuel </td><td style="text-align:center">Improve PT_MV_STRING8 support </td></tr>
<tr>
<td style="text-align:center">03/03/08 </td><td style="text-align:center"><b>0.1</b> </td><td style="text-align:center">Julien Kerihuel </td><td style="text-align:center">Initial Revision </td></tr>
</table>
<br>
<p>
<a class="anchor" name="introduction"></a><h2>1. Introduction</h2>
<p>
OCPF stands for OpenChange Property Files. This is a tiny file format designed for scripting and which facilitates third-party applications interaction and developers work using OpenChange. The main objective of OCPF is to offer the possibility to go beyond OpenChange tools default properties and create a custom message with user-defined fields. <br>
<p>
<a class="anchor" name="purpose"></a><h2>2. Purpose and Scope</h2>
<p>
OCPF is designed to be used in various kind of applications and for different purposes: <ul>
<li>
<b>Research on properties</b>: OpenChange developers have often requested for an easy way to test properties and properties values. Prior to OCPF, developers had to write an application linked with libmapi and compile it so that they could test properties. Moreover, adding new named properties in trunk was kept under OpenChange commiters agreement. OCPF solves this issue and allow developers to write OCPF files with custom properties that they can send using OpenChange tools. Furthermore OCPF will provide the community a convenient way to agree on a particular property.<p>
</li>
<li>
<b>Web Applications</b>: OCPF offers a scripted language with substitution variables which makes it possible to use OCPF templates and use OCPF in conjunction with Web Forms. Since OCPF API supports the parsing of multiple files, developers can plan to have a file with variable declarations and a separate OCPF template that just specifies variables.<p>
</li>
<li>
<b>Backup/Restore</b>: OCPF format may offer an easy way for a restore/backup application to dump to the local filesystem and restore messages on Exchange server. Furthermore, substitution of variables can possibly be used to maintain the new hierarchy, such as changing folders ID across Exchange servers and help migrating database from a server to another.<p>
</li>
</ul>
<br>
<p>
<a class="anchor" name="limit"></a><h2>3. Limitations and Bugs </h2>
<p>
OCPF is a pretty new library and it currently has a some limitations: <ul>
<li>
It only supports a very limited set of property types </li>
<li>
It doesn't support attachment yet </li>
</ul>
<p>
These limitations will be removed in later versions of OCPF.<p>
If you find bugs, limitations or encounter issues while using the OCPF library, please consider reporting them on <a href="http://trac.openchange.org">http://trac.openchange.org</a> and select the libocpf component. (Note: registration is required to create new tickets).<p>
For questions about its usage or about libocpf development, please post on the <a href="http://mailman.openchange.org/listinfo/devel">OpenChange devel mailing-list.</a> <br>
<p>
<a class="anchor" name="syntax"></a><h2>4. Syntax</h2>
<p>
The general OCPF syntax is pretty basic. It mostly consists of top-level keywords, sections and properties types. <br>
<p>
<a class="anchor" name="keywords"></a><h2>5. Top Level Keywords</h2>
<p>
<a class="anchor" name="type"></a><h3>5.1 TYPE </h3>
<p>
<ul>
<li>
<b>Format:</b> <div class="fragment"><pre class="fragment"> TYPE STRING
</pre></div> <p>
</li>
<li>
<b>Description:</b><p>
This keyword specifies the message class of the message. Users can either specify their custom type or use on of the following standard values: <ul>
<li>
"IPM.Appointment" </li>
<li>
"IPM.Contact" </li>
<li>
"IPM.Journal" </li>
<li>
"IPM.Note" </li>
<li>
"IPM.StickyNote" </li>
<li>
"IPM.Task" </li>
<li>
"IPM.Post" </li>
</ul>
</li>
<li>
<b>Note:</b><p>
TYPE can only be defined once and takes a string value as parameter. String values must be quoted otherwise a <em>syntax error</em> will be displayed on output. </li>
<li>
<b>Example:</b> <div class="fragment"><pre class="fragment"> TYPE <span class="stringliteral">"IPM.Appointment"</span>
</pre></div> </li>
</ul>
<br>
<p>
<a class="anchor" name="folder"></a><h3>5.2 FOLDER </h3>
<p>
<ul>
<li>
<b>Format:</b> <div class="fragment"><pre class="fragment"> FOLDER STRING
FOLDER DOUBLE
FOLDER VAR
</pre></div> </li>
<li>
<b>Description:</b><p>
This keyword defines the destination folder of the message. Users can either specify a default folder using the string value or a custom folder ID using its PR_FID double value. It is also possible to substitute the value with a variable, but it is limited to DOUBLE value.<p>
When FOLDER is set with DOUBLE custom value and ocpf_OpenFolder public function used, it can be set to any folder identifier within the message store. The function will loop over mailbox folders until it finds the folder with the given folder ID and opens it.<p>
Possible STRING values: <ul>
<li>
olFolderTopInformationStore </li>
<li>
olFolderDeletedItems </li>
<li>
olFolderOutbox </li>
<li>
olFolderSentMail </li>
<li>
olFolderInbox </li>
<li>
olFolderCommonView </li>
<li>
olFolderCalendar </li>
<li>
olFolderContacts </li>
<li>
olFolderJournal </li>
<li>
olFolderNotes </li>
<li>
olFolderTasks </li>
</ul>
</li>
<li>
<b>Note:</b><p>
FOLDER can only be defined once. </li>
<li>
<b>Examples:</b> <div class="fragment"><pre class="fragment">FOLDER <span class="stringliteral">"olFolderCalendar"</span>
</pre></div><p>
or<p>
<div class="fragment"><pre class="fragment">FOLDER D0x9504000000000001
</pre></div><p>
or<p>
<div class="fragment"><pre class="fragment">SET $folder_id = D0x9504000000000001
FOLDER $folder_id
</pre></div> </li>
</ul>
<br>
<p>
<a class="anchor" name="set"></a><h3>5.3. SET</h3>
<p>
<ul>
<li>
<b>Format:</b> <div class="fragment"><pre class="fragment"> SET VAR = PROPVALUE
</pre></div> </li>
<li>
<b>Description:</b><p>
This keyword registers a variable named VAR and sets its value to PROPVALUE. Variables must be prefixed with a dollar sign ($) and their value can be set to any supported property type. See section on property values for further information. <p>
</li>
<li>
<b>Note:</b><p>
SET can be used as many times as needed by the user, however VAR name must remain unique. When a variable name is registered for the second time, the OCPF parser displays a warning on the standard output and skips the assignment. <p>
</li>
<li>
<b>Example:</b> <div class="fragment"><pre class="fragment"> SET $var1 = 0xdeadbeef
SET $var2 = <span class="stringliteral">"Hello World"</span>
SET $var3 = T2008-03-06 23:30:00
</pre></div> </li>
</ul>
<br>
<p>
<a class="anchor" name="oleguid"></a><h3>5.4. OLEGUID</h3>
<p>
<ul>
<li>
<b>Format:</b> <div class="fragment"><pre class="fragment"> OLEGUID IDENTIFIER STRING
</pre></div> </li>
<li>
<b>Description:</b><p>
This keyword registers an OLEGUID couple (IDENTIFIER and STRING value) that can then be used when declaring named properties (see NPROPERTY). OLEGUID keyword takes two parameters: first the name, used with named properties (PSETID_Appointment, PS_PUBLIC_STRINGS etc.) and secondly a string representing a GUID value. </li>
<li>
<b>Note:</b><p>
OLEGUID are identified by their IDENTIFIER and STRING. Users can't register the same OLEGUID IDENTIFIER or STRING twice. If such case occurs, a warning message will be displayed on stdout. </li>
<li>
<b>Example:</b> <div class="fragment"><pre class="fragment"> OLEGUID PSETID_Appointment <span class="stringliteral">"00062002-0000-0000-c000-000000000046"</span>
[...]
NPROPERTY {
OOM:Label:PSETID_Appointment = T2008-03-06 23:30:00
[...]
</pre></div> </li>
</ul>
<br>
<p>
<a class="anchor" name="recipient"></a><h3>5.5. RECIPIENT </h3>
<p>
<ul>
<li>
<b>Format:</b> <div class="fragment"><pre class="fragment"> RECIPIENT TO STRING;STRING;STRING
RECIPIENT CC STRING;STRING
RECIPIENT BCC STRING
</pre></div> </li>
<li>
<b>Description:</b><p>
This keyword declares recipients. RECIPIENT is followed by a recipient type (TO, CC or BCC) and a set of STRING (recipients) separated with semicolon. </li>
<li>
<b>Example:</b> <div class="fragment"><pre class="fragment"> RECIPIENT TO <span class="stringliteral">"recipient1"</span>;<span class="stringliteral">"recipient2"</span>;<span class="stringliteral">"recipient3"</span>
RECIPIENT CC <span class="stringliteral">"recipient4"</span>
RECIPIENT BCC <span class="stringliteral">"recipient5@remote.corp"</span>;<span class="stringliteral">"recipient6"</span>
</pre></div> </li>
</ul>
<br>
<p>
<a class="anchor" name="property"></a><h3>5.6. PROPERTY section</h3>
<p>
<ul>
<li>
<b>Format:</b> <div class="fragment"><pre class="fragment"> PROPERTY {
[...]
};
</pre></div> </li>
<li>
<b>Description:</b><p>
This keyword declares a <em>known property</em> section. PROPERTY is followed by an opening brace, a set of property declarations and is ended with a closing brace and semicolon. This section only recognizes properties as described in <a href="#properties">6. Known properties</a>. </li>
<li>
<b>Note:</b><p>
While we suggest keeping a single PROPERTY section, nothing prevents the user from declaring as many PROPERTY sections as needed. </li>
<li>
<b>Example:</b> <div class="fragment"><pre class="fragment"> PROPERTY {
PR_SUBJECT = <span class="stringliteral">"Hello World"</span>
0x1000001e = <span class="stringliteral">"Sample body content"</span>
};
</pre></div> </li>
</ul>
<br>
<p>
<a class="anchor" name="nproperty"></a><h3>5.7. NPROPERTY section</h3>
<p>
<ul>
<li>
<b>Format:</b> <div class="fragment"><pre class="fragment"> NPROPERTY {
[...]
};
</pre></div> </li>
<li>
<b>Description:</b><p>
This keyword declares a <em>named property</em> section. NPROPERTY is followed by an opening brace, a set of named properties declarations and is ended with a closing brace and semicolon. This section only recognizes named properties as described in <a href="#nproperties">7. Named Properties</a>.<p>
</li>
<li>
<b>Note:</b><p>
While we suggest keeping a single NPROPERTY section, nothing prevents the user from declaring as many NPROPERTY sections as needed. </li>
<li>
<b>Example:</b> <div class="fragment"><pre class="fragment"> NPROPERTY {
OOM:Start:PSETID_Appointment = T2008-03-06 22:00:00
OOM:Location:PSETID_Appointment = <span class="stringliteral">"Home Sweet Home"</span>
<span class="comment">/* Meeting Status */</span>
MNID_ID:0x8217:PSETID_Appointment = 0;
};
</pre></div> </li>
</ul>
<br>
<br>
<p>
<a class="anchor" name="properties"></a><h2>6. Known Properties</h2>
<p>
A known properties is any property where the value doesn't change across Exchange servers and versions. Known properties can only be registered within a PROPERTY section (See <a href="#property">5.6 PROPERTY section</a>). Known properties have the same general syntax:<p>
<div class="fragment"><pre class="fragment"> IDENTIFIER = [PROPVALUE | VAR]
INTEGER = [PROPVALUE | VAR]
</pre></div><p>
OCPF lets the user define <em>known properties</em> using two different methods: property names or property tags.<p>
Please note that OCPF doesn't check whether the value associated with the property matches the property type. For the moment it is the developer's responsibility to ensure that the property type matches its value. <br>
<p>
<a class="anchor" name="propname"></a><h3>6.1. Property Names</h3>
<p>
Property Names are defined with an IDENTIFIER which must match one already registered in libmapi/conf/mapi-properties. For example: <div class="fragment"><pre class="fragment"> PR_SUBJECT = <span class="stringliteral">"Hello World"</span>
PR_START_DATE = T2008-03-06 22:00:00
PR_PRIORITY = 2
</pre></div> <br>
<p>
<a class="anchor" name="proptag"></a><h3>6.2. Property Tags</h3>
<p>
Property Tags are the other way to set a property. This is an integer value represented using hexadecimal notation and which has two parts: the upper 16 bits are the property ID and the lower 16 bits are the property type.<p>
While users may prefer to use the property name notation for declaration, libmapi/conf/mapi-properties remains incomplete and there may be cases where you need to use the property tag notation. The example below sets properties described in previous example using their property tag notation. <div class="fragment"><pre class="fragment"> 0x0037001e = <span class="stringliteral">"Hello World"</span>
0x00600040 = T2008-03-06 22:00:00
0x00260003 = 2
</pre></div>. <br>
<p>
<a class="anchor" name="nproperties"></a><h2>7. Named Properties</h2>
<p>
The OCPF syntax for different kind of named properties is quite generic. It supports each of the three kinds of property (OOM, MNID_ID, MNID_STRING) and can set known named properties (those listed in libmapi/conf/mapi-named-properties) or register new named properties (except OOM properties).<p>
The types of properties, and how they can be used, are described below. <br>
<p>
<a class="anchor" name="OOM"></a><h3>7.1. OOM</h3>
<p>
OOM stands for Outlook Object Model and is a friendly name associated to a named property. It has no meaning to Exchange, but it can be useful for OpenChange or MAPI developers.<p>
OOM are human readable shortcuts for most named properties and OOM values are are considered reliable. This is the reason why OOM can only be used if it exists in libmapi/conf/mapi-named-properties. This method - in our opinion - is the best method to guarantee developers a common and validated mapi-named-properties file.<p>
Theorically, property names can have the same OOM, property ID (MNID_ID) or name (MNID_STRING). The only way to guarantee named property uniqueness is to associate its value with a OLEGUID.<p>
OLEGUID needs to be registered before they can be used with named properties. See <a href="#oleguid">5.4 OLEGUID</a> for more information on how to register a OLEGUID.<p>
OOM named properties have the following syntax: <div class="fragment"><pre class="fragment"> OOM:IDENTIFIER:IDENTIFIER = [PROPVALUE | VAR]
</pre></div><p>
The first IDENTIFIER represents the OOM value while the second one represents the OLEGUID. Note that identifiers are not enclosed with quotes. Below are some OOM assignments examples:<p>
<div class="fragment"><pre class="fragment"> OOM:Label:PSETID_Appointment = 9
OOM:End:PSETID_Appointment = $end_date
OOM:Private:PSETID_Common = B<span class="stringliteral">"true"</span>
</pre></div> <br>
<p>
<a class="anchor" name="MNID_ID"></a><h3>7.2. MNID_ID</h3>
<p>
Named properties that Exchange converts using their property ID (16 bits) are known as MNID_ID named property kind. OCPF provides two different ways to define MNID_ID. It can either be a new named property or an existing one which wouldn't have any associated OOM.<p>
MNID_ID named property kind has the following syntax: <div class="fragment"><pre class="fragment"> MNID_ID:INTEGER:PROPTYPE:IDENTIFIER = [PROPVALUE | VAR]
MNID_ID:INTEGER:IDENTIFIER = [PROPVALUE | VAR]
</pre></div><p>
If the MNID_ID named property doesn't exist within libmapi/conf/mapi-named-property then you must specify its property type.<p>
As described in the example below, the main difference between known and custom MNID_ID named properties is whether or not we specify its property type. If your MNID_ID property has not been referenced within libmapi/conf/mapi-named-property, then you must supply its property type, otherwise you can skip it.<p>
Note: PROPTYPE can be any of the values described in <a href="#proptype">8. Supported Property Types </a>.<p>
<div class="fragment"><pre class="fragment"> MNID_ID:0x8501:PT_LONG:PSETID_Common = $reminder <span class="comment">/* Reminder */</span>
MNID_ID:0x8217:PSETID_Appointment = 0 <span class="comment">/* MeetingStatus */</span>
</pre></div> <br>
<p>
<a class="anchor" name="MNID_STRING"></a><h3>7.3. MNID_STRING</h3>
<p>
Exchange also supports named properties which do not have a property ID but are described using property names. These named properties are known as MNID_STRING named property kind and Exchange maps these names to a temporary property type.<p>
MNID_STRING named property kind has the following syntax: <div class="fragment"><pre class="fragment"> MNID_STRING:STRING:IDENTIFIER = [PROPVALUE | VAR]
MNID_STRING:STRING:PROPTYPE:IDENTIFIER = [PROPVALUE | VAR]
</pre></div><p>
MNID_STRING difference between known and custom is the same as MNID_ID one. If the MNID_STRING property doesn't exist in libmapi/conf/mapi-named-properties, then users have to supply its PROPTYPE.<p>
NOTE: PROPTYPE can be any of the value described in <a href="#proptype">8. Supported Property Types </a>.<p>
Considering the behavior described above, we could set the "Keywords" MNID_STRING named property using any of the following example: <div class="fragment"><pre class="fragment"> MNID_STRING:<span class="stringliteral">"Keywords"</span>:PS_PUBLIC_STRINGS = {<span class="stringliteral">"one"</span>, <span class="stringliteral">"two"</span> , <span class="stringliteral">"three"</span> }
MNID_STRING:<span class="stringliteral">"Keywords"</span>:PT_MV_STRING8:PS_PUBLIC_STRINGS = {<span class="stringliteral">"one"</span>, <span class="stringliteral">"two"</span> , <span class="stringliteral">"three"</span> }
</pre></div><p>
<br>
<p>
<a class="anchor" name="proptype"></a><h2>8. Supported Property Types</h2>
<p>
<a class="anchor" name="boolean"></a><h3>8.1. PT_BOOLEAN</h3>
<p>
OCPF uses the following format for BOOLEAN values: <div class="fragment"><pre class="fragment"> B<span class="stringliteral">"true"</span>
B<span class="stringliteral">"false"</span>
</pre></div> <br>
<p>
<a class="anchor" name="short"></a><h3>8.2. PT_SHORT</h3>
<p>
OCPF can use any of the following formats for SHORT values: <div class="fragment"><pre class="fragment"> S0x1234
S32
</pre></div><p>
The short integer can either be in hexadecimal of decimal notation but must be prefixed with a "S" to specify this is a short integer value. If you omit to specify the "S", mismatch property type/value errors will occur while sending the message.<p>
<a class="anchor" name="long"></a><h3>8.3. PT_LONG</h3>
<p>
OCPF can use any of the following formats for PT_LONG values: <div class="fragment"><pre class="fragment"> 0xdeadbeef
L0xdeadbeef
32
</pre></div><p>
The integer can either be in hexadecimal or decimal notation or prefixed with a "L" to specify this is long value. If you use the hexadecimal notation consider using the 'L' prefixed form since other form may disappear in further versions. <br>
<p>
<a class="anchor" name="double"></a><h3>8.4. PT_I8</h3>
<p>
OCPF uses the following format for PT_I8 (uint64_t) values: <div class="fragment"><pre class="fragment"> D0x9504000000000001
</pre></div> <br>
<p>
<a class="anchor" name="string8"></a><h3>8.5. PT_STRING8</h3>
<p>
OCPF defines a string as a set of characters (A-Za-z0-9_) enclosed with double quotes: <div class="fragment"><pre class="fragment"> <span class="stringliteral">"I am a STRING"</span>
</pre></div> <br>
<p>
<a class="anchor" name="unicode"></a><h3>8.6. PT_UNICODE</h3>
<p>
OCPF defines a unicode string as a set of characters enclosed with double quotes and prefixed with <b>W</b>: <div class="fragment"><pre class="fragment"> W<span class="stringliteral">"I am a UNICODE string"</span>
</pre></div> <br>
<p>
<a class="anchor" name="systime"></a><h3>8.7. PT_SYSTIME</h3>
<p>
OCPF defines date using the following format string: <div class="fragment"><pre class="fragment"> TYYYY-MM-DD HH:MM:SS
</pre></div><p>
Dates are prefixed with a 'T' character and its content is represented with the syntax below:<p>
<ul>
<li>
YYYY: year </li>
<li>
MM: month </li>
<li>
DD: day </li>
<li>
HH: hours </li>
<li>
MM: minutes </li>
<li>
SS: seconds </li>
</ul>
<p>
<div class="fragment"><pre class="fragment"> T2008-03-06 22:30:00 <span class="comment">/* 2008, 6th of March 10:30:00PM */</span>
</pre></div> <br>
<p>
<a class="anchor" name="mv_string8"></a><h3>8.8. PT_MV_STRING8</h3>
<p>
PT_MV_STRING8 are arrays ("multiple values") of strings. OCPF defines PT_MV_STRING8 property values as STRING property values separated by commas and enclosed within braces.<p>
<div class="fragment"><pre class="fragment"> { STRING, STRING, ..., STRING }
</pre></div><p>
At least one STRING property value is required to create a valid PT_MV_STRING8 property. If two or more STRING property values are set, then they must be separated with comma.<p>
<div class="fragment"><pre class="fragment"> { <span class="stringliteral">"single multi-string value"</span> }
{ <span class="stringliteral">"one"</span> , <span class="stringliteral">"two"</span>, <span class="stringliteral">"three"</span>, <span class="stringliteral">"owned"</span> }
</pre></div> <br>
<p>
<a class="anchor" name="binary"></a><h3>8.9. PT_BINARY</h3>
<p>
PT_BINARY are blobs of data. OCPF defines PT_BINARY property values using two different methods. This can either be raw/inline blob of data or filename/external.<p>
If users wish to add raw data blob for a given property, they need to enclose INTEGER values within braces. However many cases occur where the data blob is large (such as HTML content; PR_HTML has PT_BINARY property type). In such cases, users may rather prefer to write an external file and specify a filename.<p>
<div class="fragment"><pre class="fragment"> { INTEGER INTEGER [...] INTEGER }
< STRING >
</pre></div><p>
Note that if the blob of data (raw or pointed by filename) is too large to fit in the property values array, then OCPF will automatically open a stream for the property and write its data in the stream.<p>
<div class="fragment"><pre class="fragment"> PR_HTML = { 0x48 0x65 0x6c 0x6c 0x6f } <span class="comment">/* Hello */</span>
PR_HTML = <<span class="stringliteral">"/tmp/sample.html"</span>>
</pre></div><p>
<a class="anchor" name="comments"></a><h2>9. Comments</h2>
<p>
OCPF files can contain comments embedded in normal C-style comment markers. That is, a comment starts with a combination of / followed by *, and ends with combination of * followed by /.<p>
Anything contained with in comment markers is ignored by the OCPF tools, and is only for the convenience of human readers.<p>
<div class="fragment"><pre class="fragment"><span class="comment">/* This is a comment */</span>
</pre></div><p>
<a class="anchor" name="tools"></a><h2>10. OCPF and openchangeclient</h2>
<p>
OCPF support has been added to the openchangeclient utility. It now has the ability to parse and process OCPF files. Two different options are supported; you can either check an OCPF files' syntax (--ocpf_syntax) or process the files (--ocpf_sender).<p>
Users can set OCPF files using --ocpf-file=filename. Note that you can specify --ocpf-file multiple times if you have split the OCPF contents into different files. However the whole OCPF files you specify must only represent a single message.<p>
Sample OCPF files are provided in the distribution (libocpf/examples), and can also be browsed from the <a href="examples.html">Examples section</a> of this documentation: <ul>
<li>
<a href="sample__appointment_8ocpf-example.html">sample_appointment.ocpf</a> </li>
<li>
<a href="sample__task_8ocpf-example.html">sample_task.ocpf</a> </li>
</ul>
<p>
<a class="anchor" name="syntax"></a><h2>10.1 ocpf_syntax</h2>
<p>
Process specified OCPF files, display syntax errors if detected and dump OCPF context content on standard output.<p>
<div class="fragment"><pre class="fragment">openchangeclient --ocpf-syntax \
--ocpf-file=libocpf/examples/sample_appointment.ocpf
</pre></div><p>
<a class="anchor" name="sender"></a><h2>10.2. ocpf_sender</h2>
<p>
Process specified OCPF files and create/send a message using OCPF context contents.<p>
<div class="fragment"><pre class="fragment">openchangeclient --ocpf_sender \
--ocpf-file=libocpf/examples/sample_appointment.ocpf
</pre></div><p>
<a class="anchor" name="dump"></a><h2>10.3 ocpf_dump</h2>
<p>
Process specified MAPI message and generates the corresponding OCPF file on the filesystem.<p>
<div class="fragment"><pre class="fragment">openchangeclient --fetch-items=Appointment
MAILBOX (1 messages)
|== test ==| : AA13000000000001/20C140000000003
Location: paris
Start time : Sat Mar 29 09:00:00 2008 CET
End time : Sat Mar 29 09:30:00 2008 CET
Timezone: (GMT+01:00) Brussels, Copenhagen, Madrid, Paris
Private: False
Status: Completed
fetchitems : MAPI_E_SUCCESS (0x0)
openchangeclient --ocpf-dump=AA13000000000001/20C140000000003
OCPF output file: 20c140000000003.ocpf
OCPF Dump : MAPI_E_SUCCESS (0x0)
</pre></div> </div>
</div>
<br/>
<table style="clear:both; margin: 0.5em auto; width:80%; text-align: center; background-color:#f8f8f8; border:2px solid #e0e0e0; padding:5px;">
<tr>
<td>
<img alt="Creative Commons License" src="CC_SomeRightsReserved.png" width="90" height="30" border="0" /><br />
<img alt="Creative Commons Attribution icon" src="24px-Cc-by_white.svg.png" width="24" height="24" border="0" />
<img alt="Creative Commons Share Alike icon" src="24px-Cc-sa_white.svg.png" width="24" height="24" border="0" />
</td>
<td> <i><strong class="selflink">This content</strong> is licensed under the Creative Commons<br />
Attribution ShareAlike License v. 3.0:<br />
<a href="http://creativecommons.org/licenses/by-sa/3.0/" class="external free" title="http://creativecommons.org/licenses/by-sa/3.0/" rel="nofollow">http://creativecommons.org/licenses/by-sa/3.0/</a></i>
</td></tr></table>
<br/>
</div>
</div>
</body>
</html>
