none
[MS-ASCMD] Search Request - ConversationId has string data type for GUID RRS feed

  • Question

  • Hi,

        This is to clarify the data type requirement specifically for Search CMD in AS 14.x

        As per [MS-ASCMD] 2.2.2.14.1.1.1.2.1.4 ConversationId (http://msdn.microsoft.com/en-us/library/ee124312%28v=EXCHG.80%29.aspx)

                   The <ConversationId> element specifies the conversation for which to search.<37> The value is a GUID .

                   The Data Type is string .

        Any other data type definitions for <ConversationId> is  always byte array

                e.g. 2.2.2.21 email2:ConversationId (http://msdn.microsoft.com/en-us/library/ee159339.aspx)

                e.g. 2.2.2.5.1 search:ConversationId (http://msdn.microsoft.com/en-us/library/ee203257%28v=EXCHG.80%29.aspx)

     

        How to generate the GUID from the bytearray?

           Is it simply a mapping of bytearray data into 128 characters  to get GUID?

           We cannot do a base64 as it will contain characters not acceptable in GUID.

       Can you please provide a live example too?

    (FYI none of the examples in the documents show the request <ConversationId>.

         Where as the <ConversationId> in response has being shown as byte array.)

     

    Thanks

    Czar

    Monday, January 17, 2011 9:46 AM

Answers

  • Hi Dominic,

         It seems i have resolved my confusion with testing against exchange server where i received the proper response.

    My approach was to to ignore what specs says i.e. the request data type for <ConversationId> should be string i replaced it with the byte array received in sync response.

          So my conclusion is that the specification has to be corrected that <ConverstationId> should be byte array for request in sync/search cmd etc.. Which was received either in Sync / Search response etc... without user intervention.

     

           Overall i would suggest instead of exchanging byte array for <ConversationId> it would be in best interest if base64 encoded data is  exchanged by both server and client.

            This helps client development to handle string data easily rather than binary data which is also no modification is allowed.

    Thanks

    Sireesh

     

    • Marked as answer by czar x Wednesday, January 19, 2011 9:25 AM
    Wednesday, January 19, 2011 9:25 AM

All replies

  • Hi Czar,

    Thank you for your question.  A colleague will follow up with you soon to investigate.

    Regards,
    Mark Miller
    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

    Monday, January 17, 2011 1:14 PM
  • Czar,

    I am the engineer who has taken ownership of your issue. I am currently investigating this and will update you as things progress.

    Dominic Salemno
    Escalation Engineer
    Open Specifications

    Monday, January 17, 2011 3:42 PM
  • Czar,

    The nature of the byte array of the conversationId element can be found in [MS-ASDTYPE] Section 2.6.1 . The byte array is encoded and transmitted as [WBXML1.2] opaque data :

    Opaque Data

    opaque = OPAQUE length *byte

    The opaque token ( OPAQUE ) encodes application-specific data. A length field and zero or more bytes of data follow the token. The length field encodes the number of bytes of data, excluding the OPAQUE token and the length field.

    I hope this information assists you.

    Dominic Salemno
    Escalation Engineer
    Open Specifications

     

    • Marked as answer by King Salemno Tuesday, January 18, 2011 7:18 AM
    • Unmarked as answer by czar x Tuesday, January 18, 2011 7:51 AM
    Tuesday, January 18, 2011 7:16 AM
  • Hi Dominic,

         Let me rephrase the question?

         The <email2:ConversationId> recevied (response sent by exchange server) by any client is in byte-array and it is OPAQUE token.

         But when a client has a request here as an example in form of Search command <ConversationId> should be a string   to represent a GUID.

         GUID is 128 byte hexadecimal characters.

         From where i will a get a GUID for a given Conversation to be searched for ?

     

    Thanks

    Sireesh

    Tuesday, January 18, 2011 7:49 AM
  • Hi Dominic,

         It seems i have resolved my confusion with testing against exchange server where i received the proper response.

    My approach was to to ignore what specs says i.e. the request data type for <ConversationId> should be string i replaced it with the byte array received in sync response.

          So my conclusion is that the specification has to be corrected that <ConverstationId> should be byte array for request in sync/search cmd etc.. Which was received either in Sync / Search response etc... without user intervention.

     

           Overall i would suggest instead of exchanging byte array for <ConversationId> it would be in best interest if base64 encoded data is  exchanged by both server and client.

            This helps client development to handle string data easily rather than binary data which is also no modification is allowed.

    Thanks

    Sireesh

     

    • Marked as answer by czar x Wednesday, January 19, 2011 9:25 AM
    Wednesday, January 19, 2011 9:25 AM
  • Sireesh,

    Thank you for your feedback. I will forward this information on to provide a proper definition in a future release of the documentation.

    Dominic Salemno
    Escalation Engineer
    Open Specifications

    Wednesday, January 19, 2011 4:03 PM
  • Sireesh,

    You could also review the [MS-ASCON] (ActiveSync Conversations Protocol Specification) Specification located here: http://msdn.microsoft.com/en-us/library/dd633488(v=EXCHG.80).aspx. This document contains a more detailed description of elements ConversationId and ConversationIndex in Section 2.2.2.2 of the aforementioned document.

    Dominic Salemno
    Escalation Engineer
    Open Specifications

    Wednesday, January 19, 2011 6:03 PM
  • Hi Dominic,

             I would definitely provide feed back on the specification.

             In my query i have referred [MS-ASCON] also.

             My focus and suggestion was specifically for [MS-ASCMD] 2.2.2.14.1.1.1.2.1.4 ConversationId

                   (available here: http://msdn.microsoft.com/en-us/library/ee124312%28v=EXCHG.80%29.aspx )

    Thanks for your support

    Sireesh

    Thursday, January 20, 2011 3:17 AM