none
MS-NSPI 3.1.4.16 NspiGetNamesFromIDs RRS feed

  • Question

  • MS-NSPI 3.1.14.16 NspiGetNamesFromIDs has several references to a ppColumns parameter which doesn't exist in the interface declaration.  Server Processing Rule 9 is especially confusing indicating this non-existent parameter as both an input and an output parameter.  Please clarify.
    Monday, August 16, 2010 11:14 PM

Answers

  • David,

     

    As for your original question regarding ppColumns in MS-NSPI 3.1.4.16 NspiGetNamesFromIDs, Server Processing Rules 1 and 9 should reference ppNames instead.  A correction will be made in a future release of the document.

     

    As for your second question regarding Server Processing rule 5(1), we reviewed it for technical accuracy and believe that it is correct.  I provided your feedback to the doc team about the section’s clarity.  Is this text blocking your work or do you need further assistance?

     

    Bryan


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Thursday, August 26, 2010 5:22 PM
    Moderator
  • David,

     

    Server processing rule 5 discusses constructing a list of proptags, which is different from the parameter pPropTags.

     

    If the parameter pPropTags is not NULL (i.e., an incoming list is supplied), 5.1 says the list we’re creating is equal to the incoming list (the list being constructed contains a copy of the parameter).  5.2 says if one is not supplied (pPropTags is NULL), then the list the server constructs contains all proptags the server knows about.

     

    5.1 must refer to the parameter by name (i.e. pPropTags).  It refers to the “list of proptags” specified in section 5.  It says the list of proptags contains those proptags in pPropTags (i.e. the list we’re constructing must have all the same proptags as the input parameter pPropTags).  Furthermore, it must be in a one-to-one order preserving correspondence.

     

    Please let me know if this resolves your issue.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    • Marked as answer by David Mott Wednesday, September 1, 2010 2:24 PM
    Monday, August 30, 2010 3:47 PM
    Moderator

All replies

  • David,

    Thank you for your question regarding MS-NSPI 3.1.14.16 NspiGetNamesFromIDs. One of our engineers will follow-up with you shortly.

    Regards,

    Edgar

    Tuesday, August 17, 2010 5:31 AM
    Moderator
  • Hi David,

     

    I'm researching this for you.

     


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Tuesday, August 17, 2010 3:59 PM
    Moderator
  • Hi Bryan, please check on rule 5 A while youre at it:

    If the input parameter pPropTags is not NULL, the list of proptags contains the proptags specified by the value of pPropTags. The list is ordered in one-to-one order preserving correspondence with the proptags specified by the input parameter pPropTags.

    I think someone was chronically sleep deprived when that one got written down.

    Monday, August 23, 2010 9:55 PM
  • Just a quick update.  Last week I reserached your issue and I initialized a dialog with the document author and protocol developer.  I expect traction soon and I'll add your concerns re Rule 5 to the dialog.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Tuesday, August 24, 2010 5:54 PM
    Moderator
  • David,

     

    As for your original question regarding ppColumns in MS-NSPI 3.1.4.16 NspiGetNamesFromIDs, Server Processing Rules 1 and 9 should reference ppNames instead.  A correction will be made in a future release of the document.

     

    As for your second question regarding Server Processing rule 5(1), we reviewed it for technical accuracy and believe that it is correct.  I provided your feedback to the doc team about the section’s clarity.  Is this text blocking your work or do you need further assistance?

     

    Bryan


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Thursday, August 26, 2010 5:22 PM
    Moderator
  • Hi Bryan, thanks for the update.

    WRT to the first inquiry, can you give me an idea of what corrections will be involved so I can account for them in my implementation?  Is it just the ppNames parameter?

    Also, WRT the second inquiry, it is somewhat inhibiting my work, I can compare behavior vs. Exchange but an accurate description would help, I don't believe this description is correct or needs some clarification.  My interpretation of this rule is:

    If the input parameter is not NULL, the input parameter contains the value of input parameter. The list is ordered in one-to-one with the input parameter specified by the input parameter.

    Or to paraphrase:

    If the parameter is not NULL then the parameter contains a value and is ordered according to it's ordering.

    Remove all the legaleze and it makes no sense to me.  Can you clarify?

    Friday, August 27, 2010 4:05 AM
  • Hi, David,

     

    As for ppColumns v ppNames, the only change is to replace 'ppColumns' with 'ppNames'.

    Let me reserach your issue re Processing Rule 5(1).


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Friday, August 27, 2010 3:58 PM
    Moderator
  • David,

     

    Server processing rule 5 discusses constructing a list of proptags, which is different from the parameter pPropTags.

     

    If the parameter pPropTags is not NULL (i.e., an incoming list is supplied), 5.1 says the list we’re creating is equal to the incoming list (the list being constructed contains a copy of the parameter).  5.2 says if one is not supplied (pPropTags is NULL), then the list the server constructs contains all proptags the server knows about.

     

    5.1 must refer to the parameter by name (i.e. pPropTags).  It refers to the “list of proptags” specified in section 5.  It says the list of proptags contains those proptags in pPropTags (i.e. the list we’re constructing must have all the same proptags as the input parameter pPropTags).  Furthermore, it must be in a one-to-one order preserving correspondence.

     

    Please let me know if this resolves your issue.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    • Marked as answer by David Mott Wednesday, September 1, 2010 2:24 PM
    Monday, August 30, 2010 3:47 PM
    Moderator
  • Hi Bryan, thanks for clearing that up!  Cheers
    Wednesday, September 1, 2010 2:25 PM