OXCMSG - Read Flags

Question

These queries relate to MS-OXCMSG v0.2, Section 2.2.3.10.1.2 "ReadFlags"

1. Is the 0x0A entry intended to mean that the 0x08 and 0x02 bits are reserved?

2. Is the 0x80 bit also reserved?

3. The description says "bitwise OR of zero or more values from the following table". What are the semantics of zero values (i.e. a flag value of 0x0)?

4. Are there a defined list of which combinations of bits are sensible, and what the semantics will be?
As an example (only) for flag value of 0x11, we have "The server sends a read report if one is pending, but does not change the mfRead bit." and "The user requests that any pending read report be canceled; Server sets mfRead bit.". Will the mfRead bit be set or not, and will the read receipt be sent or not?

Brad

Answer 1

The word 'reserved' to me implies future changes.  The value 0x80 should fall under this same category.  I have filed a bug against this section for the first two questions.

 

Question 3 the zero value would be 0x00.

 

Question 4 there isn't a defined list.  From your wording are you looking for more clarification about expected behavior from the server in regards to the use of multiple OR’d flags?

Answer 2

Tom,

The main intent of the first question was whether 0x0A implies 0x08 and 0x02 (or is it just a typo for 0x02)?

For Q3, the query relates to what happens to the PidTagMessageFlags property (and what Read / Unread receipts are generated) if the ReadFlags byte is 0x0.

For Q4, I think you've captured it. It just seems that this is a bitmask that has contradictory meaning for bits that can be set at the same time (e.g. my original example of 0x11) I'm trying to understand which bits "win".

Thanks

Brad

Answer 3

A bit more investigation (using SetMessageReadFlags, ROP=0x11; I'm still trying to get 0x66 to work) indicates that 0x00 causes the Read flag to be set.

Brad

Answer 4

Brad,

 

The documentation is being updated to clarify the reserved bits, the semantics zero value, and adding the combination of bits that are sensible.

 

Thank you for the feedback.

Answer 5

Brad,

 

The feedback on Read flags is:

 

0x0A is reserved (meaning 0x08 and 0x02).
0x80 is not used.
0x00 is "set the read flag and send the receipt."

 

From a 'list' the Read Flags are as mutually exclusive:

 

rfGenerateReceiptOnly
rfSupressReceipt
rfClearReadFlag (rfClearNotifyRead OR rfClearNotifyUnread)

 

The Documentation is being updated.  Again thank you for the feedback.

Answer 6

Brad,

The version 1.0 of the Exchange Server Protocol documents was released today.  The top-level URL for the documents can be found here http://msdn.microsoft.com/en-us/library/cc307725(EXCHG.80).aspx.  

You can also download the zip file that contains the PDF version of the Exchange Server Protocol documents http://go.microsoft.com/fwlink/?LinkId=115

As per this discussion I've added a snippet of the table covering the ReadFlags from the version 1.0 of [MS_OXCMSG].  

<snippet source="[MS_OXCMSG]">

2.2.3.10.1.2 ReadFlags

1-byte containing a bitwise OR of zero or more values from the following table. The server modifies bits on the PidTagMessageFlags property. The flags, frGenerateReceiptOnly, rfsuppressReceipt, and rfClearReadFlag, (rfClearNotifyRead OR rfClearNotifyUnread), are mutually exclusive.

Name	Value	Description
rfDefault	0x00	The server sets the read flag and sends the receipt.
rfSuppressReceipt	0x01	The user requests that any pending read report be canceled; Server sets mfRead bit.
rfReserved	0x0A	Ignored by the server.
rfClearReadFlag	0x04	Server clears the mfRead bit; Client MUST include rfSuppressReceipt with this flag.
rfGenerateReceiptOnly	0x10	The server sends a read report if one is pending, but does not change the mfRead bit.
rfClearNotifyRead	0x20	The server clears the mfNotifyRead bit, but does not send a read report.
rfClearNotifyUnread	0x40	The server clears the mfNotifyUnread bit, but does not send a non-read report.

</snippet>

If you have any questions or find any discrepancies in the new documentation please don’t hesitate to post questions or feedback to this forum.

Thank you for your great feedback.

---

Developer Consultant