Header Specification Comments

["Miller, Robert (GEIS)" <Robert.Miller@geis.ge.com>]

I think the Headers should not be defined as a set of levels, but rather as
a single complete header specification. Division may lead to implementation
of only certain 'levels' or perhaps to different behavior of a given
function at different levels, either of which would reduce interoperability.
I do agree that it is worthwhile to show both simple and more complex
scenarios for the use of headers.

I do not feel it is appropriate at this time to show any actual XML syntax
for the headers.  In the examples there is a mixture of XML syntax and
logical content.  We do need to work with other ebXML teams to resolve ebXML
syntax rules to be followed.  I would expect that the header XML conform to
the same rules as any ebXML document.  

The specification is not clear on the representations of the 'Header
Envelope' and 'Message Body'. I think 'Header Envelope' should be labeled
'ebXML Header', and be the ebXML Header document.  I'm not sure 'Message
Body' exists at all, it may just be the unwrapped collection of individual
'Message Body Part's, I cannot tell from the specification.

I identified some issues with message routing with SMIME, and proposed some
changes to address them.

I propose the following MIME wrappings, (when SMIME is not in use)

Multipart Related
      XML - Message Routing History	(Optional. The shell (perhaps empty)
must be present if trace history is requested.)
	XML - Message Routing Entry	(Optional)
	XML - ebXML Header		(Required)	
	??? - Body Part 1			(Optional 0-n)	
	??? - ...
	??? - Body Part n 
 
When SMIME is in use, I propose that the top two constructs, 'Multipart
Related' and 'XML - Messsage Routing History' remain outside the span of
SMIME use, and that only SMIME signature be pemitted on 'Message Routing
Entry'.  Other than that, I propose we place no ebXML constraints on use of
SMIME constructs.  Note that additional 'multipart' constructs may therefore
be established within the SMIME envelopes to support security applied
simultaneously to contiguous parts of the 'Multipart Related' content.  

I relocated 'Message Routing History' from the ebXML Header, where it was
embedded as a part of Message Routing Information, so that SMIME could be
applied to the ebXML header if so desired.

I relocated 'Message Routing Entry' from the ebXML Header to a separate
construct, so that the header could be encrypted if desired.  If
the 'Message Routing Entry' is signed, I propose we require the signature be
validated prior by each handler prior to acting upon the routing
information.

I think it is acceptable to have a no 'Message Body'.  Examples might
include error reporting and 'ping'ing.

Cheers,
        Bob