none
[MS-NSPI] / [MS-OXOABK] Query / Comments on address book behaviour RRS feed

  • Question

  • [MS-NSPI] 2.2.6 describes unicode comparison flags, and refers outs out to [MS-UCODEREF]. [MS-UCODEREF] does list the various flags, but it doesn't actually define their values (e.g. there is a symbolic value, and some behaviour description, but not a hex value for the flag).

    Q1. Can you please provide the flag values for each name in MS-NSPI Section 2.2.6?

     

    [MS-NSPI] Section 4 shows indicative values in the form of monospace text. Here is an example:

    dwFlags
    0x00000000unsigned long
    pStat
    hIndex0x00000000unsigned long
    ContainerID0x00000000unsigned long
    CurrentRec0x00000000unsigned long
    Delta0x00000000long
    NumPos0x00000000unsigned long
    TotalRecs0x00000000unsigned long
    CodePage0x000004e4unsigned long
    TemplateLocale0x00000409unsigned long
    SortLocale0x00000409unsigned long
    pServerGuid
    pointer to an array of 16 unsigned char to be returned by the server
    
    Comment 1. That is fairly hard to read. Either more spaces between elements, or layout in the form of a table might be helpful.

    Comment 2. There are cases where the indent is not consistent, which could also be improved.

     

    There is a description in [MS-NSPI] Section 4:

    When processing the NspiQueryRows method, the NSPI server implemented on Microsoft
    Windows® Server operating system enforces time and size constraints, limiting the number of
    rows returned to be less than the number of rows requested, if the limits of the constraints are
    reached. These constraints are local policy and are not configurable or discoverable via the NSPI
    Protocol.
    

    Comment 3: That would be more appropriate in [MS-NSPI] Appendix B.

     

    [MS-NSPI] Section 4 contains this description:

    6. The server responds to the NspiQueryRows call with return code Success and a row set.
    Note Not all parameters are shown, only relevant information.
    Typical return parameters are as follows.
    dwFlags
    0x00000000unsigned long
    pStat
    hIndex0x00000000unsigned long
    ContainerID0x00000000unsigned long
    CurrentRec0x00001928unsigned long
    Delta0x00000000long
    NumPos0x00000002unsigned long
    TotalRecs0x00000016unsigned long
    CodePage0x000004e4unsigned long
    TemplateLocale0x00000409unsigned long
    SortLocale0x00000409unsigned long
    dwEphsCount 0x00000000unsigned long
    lpEphs
    0x00000000unsigned long *
    Count
    0x00000002unsigned long
    pPropTags_PropertyRowSet_r * *
    {
    cRows=0x00000007
    aRow=<a pointer to an array of rows>
    }
    In this example, the server has returned a total of 0x3 rows denoted as [0x0]...[0x2] equal to
    the number of rows requested by the client. Each row typically looks like this.
    aRow[0x0] ... [0x1]_PropertyRow_r *
    {
    Reserved=0x00000000
    cValues=0x00000004
    lpProps=<a pointer to an array of columns>
    }
    

    The top part shows cRows == 7, the next part shows 0x3 rows ([0x0] .. [0x2]) and the last part shows [0x0] ... [0x1] (i.e. two rows).

    Comment 4: It would make more sense if the example was consistent.

    [MS-OXOABK] has some of the same formatting issues, but overall is a better example of essentially the same operations.

    Comment 5: It might be better to just put the information into one document. This could provide an opportunity to show some of the other NSPI / address book operations (e.g. modifying a property, or deleting a property).

     

    [MS-OXOABK] Section 2.2.3.12 has a table showing dtRemote and dtLocal values as 32 bit values, but these values are only 1 byte.

    Comment 6: It would be better to show the values with the correct size.

     

    [MS-OXOABK] Section 2.2.4.66 describes the X.509 certificate structure.

    Comment 7: This is difficult to understand. An example would be useful.

    Wednesday, November 10, 2010 3:45 AM

Answers

  • Brad,

     

    This is in response to your comments regarding [MS-NSPI].  I broke your comments into four components.

     

    (1)

     

    Re “[MS-NSPI] 2.2.6 describes unicode comparison flags”:

     

    The flag values are as follows (from the header winnls.h, which is available in the SDK and DDK/WDK):

     

    //

    //  String Flags.

    //

    #define NORM_IGNORECASE           0x00000001  // ignore case

    #define NORM_IGNORENONSPACE       0x00000002  // ignore nonspacing chars

    #define NORM_IGNORESYMBOLS        0x00000004  // ignore symbols

     

    #define LINGUISTIC_IGNORECASE     0x00000010  // linguistically appropriate 'ignore case'

    #define LINGUISTIC_IGNOREDIACRITIC 0x00000020  // linguistically appropriate 'ignore nonspace'

     

    #define NORM_IGNOREKANATYPE       0x00010000  // ignore kanatype

    #define NORM_IGNOREWIDTH          0x00020000  // ignore width

    #define NORM_LINGUISTIC_CASING    0x08000000  // use linguistic rules for casing

     

    [...]

     

    #define SORT_STRINGSORT           0x00001000  // use string sort method

     

    I filed a request with the documentation team to add these to [MS-NSPI] or [MS-UCODEREF]

     

    (2)

     

    Re the formatting of text of code fragments in Section 4:

     

    I filed a request with the documentation team to improve the formatting and make the text more readable.

     

    (3)

     

    Re [MS-NSPI] Section 4 (Protocol Examples) Sequence #4 containing a Windows behavior note:

     

    I filed a request with the product group to consider moving this text to Appendix B “Product Behavior” with a reference to the behavior note.

     

    (4)

     

    Re the consistency of the three samples in Sequence 6 where one example illustrates seven rows, the second three and the last shows two:

     

    I provided this feedback to the documentation team.

     

    Please let me know if the above information resolves these issues.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Friday, November 12, 2010 5:10 PM
    Moderator
  • Brad, I'll look into this to see if it would be possible to get an example of each certificate format type added to the document. I'll let you know when I have more information.
    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    • Marked as answer by Brad Hards Tuesday, November 16, 2010 1:00 AM
    Monday, November 15, 2010 8:09 PM
    Moderator

All replies

  • Hi Brad,

    Thanks for pointing this out.  A colleague will follow up with you to investigate this.

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

     

    Wednesday, November 10, 2010 11:37 AM
  • Hi Brad,

     

    I am reseraching your comments that are directed toward [MS-NSPI].


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Wednesday, November 10, 2010 11:43 PM
    Moderator
  • Hi Brad, I will be working with you on your comments regarding the MS-OXOABK document.
    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Thursday, November 11, 2010 7:10 PM
    Moderator
  • Brad, regarding comments 5 and 6, I have filed requests to have those sections updated or fixed.
    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Friday, November 12, 2010 5:04 PM
    Moderator
  • Brad,

     

    This is in response to your comments regarding [MS-NSPI].  I broke your comments into four components.

     

    (1)

     

    Re “[MS-NSPI] 2.2.6 describes unicode comparison flags”:

     

    The flag values are as follows (from the header winnls.h, which is available in the SDK and DDK/WDK):

     

    //

    //  String Flags.

    //

    #define NORM_IGNORECASE           0x00000001  // ignore case

    #define NORM_IGNORENONSPACE       0x00000002  // ignore nonspacing chars

    #define NORM_IGNORESYMBOLS        0x00000004  // ignore symbols

     

    #define LINGUISTIC_IGNORECASE     0x00000010  // linguistically appropriate 'ignore case'

    #define LINGUISTIC_IGNOREDIACRITIC 0x00000020  // linguistically appropriate 'ignore nonspace'

     

    #define NORM_IGNOREKANATYPE       0x00010000  // ignore kanatype

    #define NORM_IGNOREWIDTH          0x00020000  // ignore width

    #define NORM_LINGUISTIC_CASING    0x08000000  // use linguistic rules for casing

     

    [...]

     

    #define SORT_STRINGSORT           0x00001000  // use string sort method

     

    I filed a request with the documentation team to add these to [MS-NSPI] or [MS-UCODEREF]

     

    (2)

     

    Re the formatting of text of code fragments in Section 4:

     

    I filed a request with the documentation team to improve the formatting and make the text more readable.

     

    (3)

     

    Re [MS-NSPI] Section 4 (Protocol Examples) Sequence #4 containing a Windows behavior note:

     

    I filed a request with the product group to consider moving this text to Appendix B “Product Behavior” with a reference to the behavior note.

     

    (4)

     

    Re the consistency of the three samples in Sequence 6 where one example illustrates seven rows, the second three and the last shows two:

     

    I provided this feedback to the documentation team.

     

    Please let me know if the above information resolves these issues.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Friday, November 12, 2010 5:10 PM
    Moderator
  • Brad, regarding comment 6, could you provide some additional information on what you are having difficulties with? The X.509 certificate format is not a Microsoft standard and is covered by RFC3280.
    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Friday, November 12, 2010 7:30 PM
    Moderator
  • Bryan,

    Thanks for the fast response. This does resolve issues 1-4, and Josh has resolved issue 5, but it looks like we're still discussing 6, so I'm going to unmark this as an answer until we get that last bit resolved.

    Brad

    Friday, November 12, 2010 11:29 PM
  • Josh,

    The problem is that this is a pretty complex data structure, with inter-related components, but there is not enough context-type information to understand what it would actually look like. I'm confident I could use the information to decode this property, but I don't think I could reliably construct this property using only the information in this section. I don't have anything specific (other than to suggest an example of each of the two cases - BLOB and PtypMultipleBinary), and perhaps some information on any constraints that the certificate(s) need to contain for interoperability.

    [Background: I'm preparing for implementation, working through the documentation, and that is the bit where I get the "hmm, thats going to be hard, defer that to later" response. This is a pretty low priority issue though - I'll probably be able to make more sense out of it when I see some examples from Outlook. For your consideration.].

    Brad

    Friday, November 12, 2010 11:43 PM
  • Brad, I'll look into this to see if it would be possible to get an example of each certificate format type added to the document. I'll let you know when I have more information.
    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    • Marked as answer by Brad Hards Tuesday, November 16, 2010 1:00 AM
    Monday, November 15, 2010 8:09 PM
    Moderator
  • Josh,

    Thanks for this.

    Brad

    Tuesday, November 16, 2010 1:00 AM