Re: Proposed resolution of issue 101: relationship between headerand body blocks

Um... question... if the header block cannot reference the body block, how 
in the world are we going to put digital signatures of the body content 
into the header (see the SOAP-SEC digital signature note [1])?  How are we 
going to allow encrypted session keys used to encrypt the body to be 
carried within the header?  How in the world would we be able to do things 
like a manifest header if needed? Potentially significant problems there 
if a header cannot reference body content and vice versa.

[1] -

- James M Snell/Fresno/IBM
    Web services architecture and strategy
    Internet Emerging Technologies, IBM
    544.9035 TIE line
    559.587.1233 Office
    919.486.0077 Voice Mail
Have I not commanded you?  Be strong and courageous.  Do not be terrified, 

do not be discouraged, for the Lord your God will be with you wherever you 
- Joshua 1:9

Sent by:
Subject:        Re: Proposed resolution of issue 101: relationship between headerand body 

Jean-Jacques wrote:
>So what seems to be on the plate right now is:
>* to reinforce the distinction between body and header (i101)
>* to disallow references from body to header (i170)
>* to allow only one body block per message
>This gives the picture of a very narrowedly corseted protocol,
>especially when contrasted with a generic XML document, where the
>flow of blocks is contrainted only by schemas at design time. Are we
>not being too restrictive with ourselves? Shouldn't we be more open
>in the core protocol, and defer specialisation to niches?

I do not believe the current proposal (i101) would disallow
multiple children under *the* body block.  Just like soap 1.1
there is just one XML element named "body" but there could be
multiple children under it - each one could be a separate
and independent block (ie. boxcarring), but how that is processed
would be outside the scope of the soap 1.2 spec.


Received on Tuesday, 27 November 2001 12:40:10 UTC