- From: Glen Daniels <gdaniels@sonicsoftware.com>
- Date: Wed, 29 Oct 2003 23:40:13 -0500
- To: paul.downey@bt.com, alewis@tibco.com
- Cc: www-ws-desc@w3.org
Paul: I heartily agree with your estimation that in general, the body is destined for the actual application code, and the headers are either meant for intermediaries or the infrastructure/middleware code on the server or client systems. The features that are provided by those headers may well expose data or APIs to the application layer code, but the headers themselves typically will be processed by the lower layers. Example - an application typically isn't going to get an actual copy of the security header for an ecryption/digsig extension. Rather, some lower layer software will handle key management and decryption so that the plaintext body is delivered to the application code, along with a means (sideband data in some kind of context object, or an API) for getting the name of the principal who sent the message, etc. --Glen ----- Original Message ----- From: <paul.downey@bt.com> To: <alewis@tibco.com> Cc: <www-ws-desc@w3.org> Sent: Wednesday, October 29, 2003 10:42 AM Subject: RE: PROPOSAL: Drop interface/operation/(input|output)/@headers Amy wrote: > A number of specifications currently going forward use headers to supply metainformation to the ultimate receiver. See, for instance, WS-Addressing, WS-Security (in some use cases; can also be intermediary), WS-RM. In the case of these protocols i'd expect helpers from a toolkit rather than having to understand the protocol in each application.. Given the application will probably have to plug-in the actual values, intermediary was probably the wrong word to use - sorry! > Actually, Glen and I were both at an interop dealie for WS-RM recently .. i did wonder - i read Glen's blog and spotted your name on the WS-ReliableMessaging spec :-) -- Paul Sumner Downey Web Services Integration BT Exact
Received on Wednesday, 29 October 2003 23:39:57 UTC