Export (0) Print
Expand All

3.2.5.5 Processing RopDeleteProperties

When the server receives a RopDeletePropertiesROP request buffer ([MS-OXCROPS] section 2.2.8.8) from the client, the server parses the buffer. The server responds with a RopDeletePropertiesROP response buffer. For details about how the server parses buffers and processes ROPs, see [MS-OXCROPS] section 3.2.5.1. For details about how the server formats buffers for the response, see [MS-OXCROPS] section 3.2.5.2.

The server MUST delete the property from the object. If the server fails to delete a property, that property, along with details of the failure, is specified in a PropertyProblem structure ([MS-OXCDATA] section 2.7) that is contained in the PropertyProblems field of the ROP response buffer.

If the server returns success, it MUST NOT have a valid value to return to a client that asks for the value of this property. If a client requests the value of this property, the server SHOULD return the NotFound error (0x8004010F) ([MS-OXCDATA] section 2.4.2) in place of a value.

For Message objects, the properties MUST be removed immediately when using the same handle. In other words, if the client uses the same handle to read those same properties using the RopGetPropertiesSpecific ROP ([MS-OXCROPS] section 2.2.8.3) or the RopGetPropertiesAll ROP ([MS-OXCROPS] section 2.2.8.4), the properties MUST be deleted. However, the deleted properties MUST NOT be persisted to the database until a successful RopSaveChangesMessage ROP ([MS-OXCROPS] section 2.2.6.3) is issued.

For Attachment objects, the properties MUST be removed immediately when using the same handle. However, the deleted properties MUST NOT be persisted to the database until a successful RopSaveChangesAttachment ROP ([MS-OXCROPS] section 2.2.6.15) and a successful RopSaveChangesMessage ROP are issued, in that order.

For Folder objects and Logon objects, the properties MUST be removed immediately without requiring another ROP to commit the change.

Show:
© 2014 Microsoft