locked
Property Name Mapping with MS-OXPROPS RRS feed

  • Question

  • Hi all,

    I'm assuming this is a very simple question, please be gentle, i'm learning :)

    I'm currently looking into Property ID to Property Name mapping and I'm a little confused what happens if the property name is contained within MS-OXPROPS.

    Looking at the example here http://blogs.msdn.com/openspecification/archive/2009/11/06/msg-file-format-part-1.aspx

    PidTagSenderEmailAddress obviously belongs in OXPROPS. If I did not know the name and just using the stream name 0x0C1F001F, without searching through OXPROPS for the 0x0C1F, which obiviously works, how do I know this exists within the protocol?

    MS-OXMSG mentions things such as

    GUID Index (15 bits): Index into the GUID stream. The table below shows the possible values. Value GUID to use
    1: Always use the GUID PS_MAPI ([MS-OXPROPS]). No GUID is stored in the GUID stream.
    2: Always use the GUID PS_PUBLIC_STRINGS ([MS-OXPROPS]). No GUID is stored in the GUID stream.

    Within the entry stream but if it is already in OXPROPS there will be no entry in the entry stream for it!?

    I'm a little confused and any help will be appreciated.

    I have a feeling the answer may simply be, it knows purely because it is part of the protocol, but I just need the answer confirming before I can proceed.

    Thank you for any help

     

    Thursday, April 15, 2010 10:29 AM

Answers

  • G'day,

    You have to have a table of known values - you can't expect to handle anything without knowing what the semantics of it are.

    In general, when your application maps its representation to the .msg representation (or .pst, or Exchange RPC representation), it will always map it to and from a specific value. So if you have a whole stack of properties (in your example, one of those will be 0x0C1F001F), you'd have a function or method that deals with each property (in your example, mapping that string back to however you deal with the sender's email address). We often use a big switch statement as a dispatcher.

    Also, carefully read MS-OXCPROPS Section 1.3.3. This is important, especially the bit that says: "0x8000 to 0xFFFF. Reserved for mapping to named properties. See [MS-NSPI] for more information about the static mapping of NSPI property names to property IDs that occurs in this ID range."

    [I don't understand your question "Within the entry stream but if it is already in OXPROPS there will be no entry in the entry stream for it!?". What is "it"? Can you try that again, with a bit of explanation?]

    Sunday, April 18, 2010 1:45 AM

All replies

  • Hi,

       Thanks for youe question.  One of team member will work on your question and post a response when the investigation is done.

     

     


    Hongwei Sun -MSFT
    Thursday, April 15, 2010 2:49 PM
  • G'day,

    You have to have a table of known values - you can't expect to handle anything without knowing what the semantics of it are.

    In general, when your application maps its representation to the .msg representation (or .pst, or Exchange RPC representation), it will always map it to and from a specific value. So if you have a whole stack of properties (in your example, one of those will be 0x0C1F001F), you'd have a function or method that deals with each property (in your example, mapping that string back to however you deal with the sender's email address). We often use a big switch statement as a dispatcher.

    Also, carefully read MS-OXCPROPS Section 1.3.3. This is important, especially the bit that says: "0x8000 to 0xFFFF. Reserved for mapping to named properties. See [MS-NSPI] for more information about the static mapping of NSPI property names to property IDs that occurs in this ID range."

    [I don't understand your question "Within the entry stream but if it is already in OXPROPS there will be no entry in the entry stream for it!?". What is "it"? Can you try that again, with a bit of explanation?]

    Sunday, April 18, 2010 1:45 AM
  • Hi Forgery23,

    Have all your questions on this forum thread been answered?  If not, please provide some details and I am happy to help.

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

    Wednesday, April 28, 2010 12:43 PM