none
[MS-OXCSTOR] SetReceiveFolder / GetReceiveFolderTable modification time RRS feed

  • Question

  • Hi,

    I'm working on implementing the server side part of RopSetReceiveFolder, and the documentation is working well for me.

    I have two questions related to this:

    1. [MS-OXCSTOR] Section 2.2.1.3 and 3.2.5.3 require that the server record the modification time for the "entry" or "row". I'm interested in what the client uses this time (as returned in RopGetReceiveFolderTable) for. For example, what are the consequences of always returning a PtypTime of all zero bits?  All one bits? Some other fixed value?

    In my particular case, I'm considering implementing this in such a way that modifying the MessageClass (add or delete) for any entry in a folder will update the modification time for every entry for that folder. I'd like to understand the consequences first though...

    2. MS-OXCSTOR Section 2.2.1.4.2.2 says that "The ValueArray ... MUST include only the following properties, in the order given, and no other properties". MS-OXCSTOR Section 3.2.5.3 says "Each row of the table contains at least the following three columns, with each column corresponding to a property. Any other columns included in the table, and the storage format for the table, are determined by the implementer". Those don't appear consistent to me. Is there something I'm missing, or is one of those incorrect?

    [Partial answers appreciated here, as available].

    Thanks

    Brad

    Tuesday, July 6, 2010 4:25 AM

Answers

  • Brad, the feature of directing certain message classes to specific folders is mainly for MAPI clients other than Outlook.  I believe that InfoPath forms may use this feature.  We cannot speculate on the ramifications to programs from other companies if someone were to not follow the specification.
    Josh Curry (jcurry) | Sr. Support Escalation Engineer | US-CSS DSC Protocols Team
    Tuesday, July 13, 2010 8:43 PM
    Moderator

All replies

  • Hi Brad:

    I have alerted Protcol Documentation Team regarding your inquiry about MS-OXCSTOR. A member of the team will be in touch soon.


    Regards, Obaid Farooqi
    Tuesday, July 6, 2010 4:52 PM
    Owner
  • Brad, regarding question #1, can you provide some additional details or an explanation of what exactly are you trying to accomplish by doing this, and why? It's possible that there may be a better way to get the functionality you are looking for.

    Thanks.


    Josh Curry (jcurry) | Sr. Support Escalation Engineer | US-CSS DSC Protocols Team
    Wednesday, July 7, 2010 9:15 PM
    Moderator
  • Brad, regarding question #2, the two sections that you mentioned are referring to two different response message types.

     

    Section 2.2.1.4.2.2 describes the response for RopGetReceiveFolderTable while section 3.2.5.3 is referring to RopSetReceiveFolder. This would explain why they appear to have conflicting information.


    Josh Curry (jcurry) | Sr. Support Escalation Engineer | US-CSS DSC Protocols Team
    Wednesday, July 7, 2010 10:32 PM
    Moderator
  • OK, on re-reading, 3.2.5.3 could just be describing internal behaviour of the server in response to a RopSetReceiveFolder. I could see how the server may not return the whole table.

    [This answers the second question - the first is still open.]

    Brad

    Thursday, July 8, 2010 4:40 AM
  • Josh,

    I'm implementing this behaviour on the server side using a set of key-value pairs.

    So the folder record looks (logically) something like:

    dn: CN=0x00000000002b0001,CN=0x0000000000280001,CN=testuser2,CN=First Organization Unit,CN=First Organization,CN=SAXICOLA,DC=openchange,DC=local
    cn: 0x00000000002b0001
    FolderType: 1
    objectClass: systemfolder
    PidTagAttrHidden: 0
    PidTagContainerClass: IPF.Note
    PidTagDisplayName: Inbox
    PidTagFolderChildCount: 0
    PidTagFolderId: 0x00000000002b0001
    PidTagParentFolderId: 0x0000000000280001
    PidTagSubFolders: TRUE
    PidTagSubFolders: FALSE
    SystemIdx: 6
    PidTagIpmAppointmentEntryId: 0x00000000002e0001
    PidTagIpmContactEntryId: 0x00000000002f0001
    PidTagIpmJournalEntryId: 0x0000000000300001
    PidTagIpmNoteEntryId: 0x0000000000310001
    PidTagIpmTaskEntryId: 0x0000000000320001
    PidTagIpmDraftsEntryId: 0x0000000000330001
    PidTagMessageClass: All
    PidTagMessageClass: IPM
    PidTagMessageClass: Report.IPM
    PidTagMessageClass: IPM.Note
    PidTagContentCount: 0

     

    So we just treat the PidTagMessageClass entries as attributes of the applicable folder (not as a separate table). So RopSetReceiveFolder just deletes the matching PidTagMessageClass attribute from the current folder (if any) and adds it to the new folder (if applicable).

    This isn't going to work out well with the modification time thing though. I can (easily) track modification time at the level of the folder, but not so easily at the level of a single PidTagMessageClass entry within a folder.

    So I'm interested in what effect this could have on a client (in particular, Outlook).

    Thursday, July 8, 2010 4:47 AM
  • Brad, thanks for providing some additional details about your first question. I will be looking into this and will let you know when I have more information.


    Josh Curry (jcurry) | Sr. Support Escalation Engineer | US-CSS DSC Protocols Team
    Thursday, July 8, 2010 7:02 PM
    Moderator
  • Brad, the feature of directing certain message classes to specific folders is mainly for MAPI clients other than Outlook.  I believe that InfoPath forms may use this feature.  We cannot speculate on the ramifications to programs from other companies if someone were to not follow the specification.
    Josh Curry (jcurry) | Sr. Support Escalation Engineer | US-CSS DSC Protocols Team
    Tuesday, July 13, 2010 8:43 PM
    Moderator