Title: Reliable / Duplicate / Message Order Inconsistencies Doug, I am not saying the ebXML MS specification should not provide advice on the use of XMLDSIG. I am saying that such advice must not be normative, as these definitions and advice might (now or in the future) conflict with the W3 specifcations. I do suspect that some of the content of section 4 would be better located in a 'higher level' ebXML document. RECOMMENDED constitutes non-normative advice (wherever it occurs in the document), and so could be present within the 'normative' section of the ebXML specification. The existing Section 4 Security Module seems to infer that this is an integral part of ebXML, whereas it is actually an integral part of another standard. As an example of my objection to the manner in which the ds: security elements are presented, I refer you to the last paragraph of 4.1.1, which states: Additional ds:Signature elements MAY be present, but their purpose is undefined by this specification. This may lead one to believe that this (ebXML) specification defines the purpose of the specifically referenced ds:Signature elements. It does not! It does provide non-normative text concerning the use of these elements, perhaps taken verbatim from the normative W3 document, perhaps not. May I suggest that 1.1.4 Caveats and Assumptions be extended to explicitly include the W3 Security work, since that knowledge is needed to comprehend section 4. With that done, perhaps some of the text in section 4 need not even be presented in this document. WRT to ds being a foreign namespace, the first paragraph of 2.3.6 # wildcard element content states: Some ebXML SOAP extension elements ... . I concur therefore that ds:Signature is not governed by this paragraph (though it is governed by the SOAP definition of foreign namespaces). The ds:Reference elements in the eb:Acknowledgement are governed by 2.3.6. Cheers, Bob