none
[MS-TDS] 2.2.6.4 (RPC Request) Clarifications sought for RPCReqBatch and RPCRequest RRS feed

  • Question

  • These questions are based on version 0.1.1 of the MS-TDS document - section 2.2.6.4

    1) The definition of "RPCReqBatch" starts with "All_HEADERS". I think this is incorrect. This element should only appear as part of "RPCRequest" (just below). Could you confirm this please?

    2) The definition of "RPCRequest" ends: "[BatchFlag / NoExecFlag]". Is the the presence of "BatchFlag" here correct? It doesn't make much sense, but its presence here is consistent with the word "SHOULD" in the detailed description below. Could you confirm the document as written is correct please?

    RFC 2119, in talking about "SHOULD", says:

    "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

    Might I suggest that the detailed description of BatchFlag does not allow someone working with this protocol to understand or carefully weight the full implications of including BatchFlag here?

    Wednesday, July 23, 2008 3:11 PM

Answers

  •  

    Hi Paul,

     

    We’ve concluded our investigation and these are the changes that we think might help clarify your doubts:

     

    Section 2.2.6.4 RPC Request

     

    RPCReqBatch      =  

                         NameLenProcID

                         OptionFlags

                         *ParameterData

     

    Instead of

     

    RPCReqBatch      =   ALL_HEADERS

                                      NameLenProcID

                                     OptionFlags

                                   *ParameterData

     

     

    And

    BatchFlag

    Distinguishes the start of the next RPC from another parameter within the current RPC. Either BatchFlag or NoExecFlag MUST <10> be present only if another RPC request is in the current batch. BatchFlag SHOULD NOT be sent after the last RPCReqBatch. If BatchFlag is received after the last RPCReqBatch is received the server MUST ignore it.

     

    Instead of

     

    BatchFlag

    Distinguishes the start of the next RPC from another parameter within the current RPC. <10> SHOULD only be present if another RPC request is in the current batch.

     

     

    These changes will show up on upcoming versions of the docs.

     

    Thanks,

     

    SEBASTIAN CANEVARI


    SEBASTIAN CANEVARI - MSFT SEE Protocol Documentation Team
    Monday, August 4, 2008 4:33 PM

All replies

  •  Paul - thank you for your inquiry. One of our Protocol Support Team members will be in touch with you soon concerning this.

    Regards,


    SEBASTIAN CANEVARI - MSFT SEE Protocol Documentation Team
    Wednesday, July 23, 2008 9:10 PM
  •  

    Hi Paul,

     

    We’ve concluded our investigation and these are the changes that we think might help clarify your doubts:

     

    Section 2.2.6.4 RPC Request

     

    RPCReqBatch      =  

                         NameLenProcID

                         OptionFlags

                         *ParameterData

     

    Instead of

     

    RPCReqBatch      =   ALL_HEADERS

                                      NameLenProcID

                                     OptionFlags

                                   *ParameterData

     

     

    And

    BatchFlag

    Distinguishes the start of the next RPC from another parameter within the current RPC. Either BatchFlag or NoExecFlag MUST <10> be present only if another RPC request is in the current batch. BatchFlag SHOULD NOT be sent after the last RPCReqBatch. If BatchFlag is received after the last RPCReqBatch is received the server MUST ignore it.

     

    Instead of

     

    BatchFlag

    Distinguishes the start of the next RPC from another parameter within the current RPC. <10> SHOULD only be present if another RPC request is in the current batch.

     

     

    These changes will show up on upcoming versions of the docs.

     

    Thanks,

     

    SEBASTIAN CANEVARI


    SEBASTIAN CANEVARI - MSFT SEE Protocol Documentation Team
    Monday, August 4, 2008 4:33 PM
  • Sebastian,

    Thank you for that clear and complete answer

    Paul Betteridge

    Tuesday, August 5, 2008 8:28 AM