[Fwd: ebXML header extension mechanism proposal]

[christopher ferris <chris.ferris@east.sun.com>]

FYI, for those of you not on the trp list...

-------- Original Message --------
Subject: ebXML header extension mechanism proposal
Date: Thu, 30 Nov 2000 09:02:39 -0500
From: christopher ferris <chris.ferris@east.sun.com>
Organization: XTC Advanced Development
To: "ebxml-transport@lists.ebxml.org" <ebxml-transport@lists.ebxml.org>

All,

This issue seemed to get lost in the discussion surrounding
the test/production indicator...

I'd like to formally resurrect the issue of adding in an explicit
extension mechanism to the ebXML headers to allow for
headers such as test/production flag, security credentials (S2ML
and/or XSignature), session context information, transaction context 
information (ie. XAML) and others which are considered
"infrastructure" as opposed to "application" specific.

  e.g.

  <!ELEMENT ebXMLHeader (Manifest, Header, 
        RoutingHeader, ANY)>

  or

  <element name="ebXMLHeader" type="ebXMLHeader"/>
  <complexType name='ebXMLHeader'>
    <element ref='Manifest' minOccurs='1'/>
    <element ref='Header' minOccurs='1'/>
    <element ref='RoutingHeader' minOccurs='0' maxOccurs="1"/>
    <any minOccurs='0' maxOccurs='*'/>
        ...
  </complexType>
        
with the addition of something along the lines of
mustUnderstand and possibly actor attributes defined.

Of course, I would suggest that to ensure interoperability
of the ebXML platform, that instead of mustUnderstand that
we adopt the opposite semantic of 'mayIgnore' for extensions
which a receiver is unprepared to handle. Thus, the only
value of mayIgnore (which would be an optional attribute)
would be 'true'. Of course, we could use the 'mustUnderstand'
attribute name and require that the only valid value
which MAY be used is 'false' and achieve the same semantic
meaning.

Extension headers MUST be namespace qualified, which means
that we would need to allow for an arbitrary list of
xmlns qualifiers in the ebXMLHeader element.

I think that at the very least, we need to allow for future
formal extensions to ebXML MS (version 2.0) which would
need to allow for backwards compatibility with version 1.0.
Thus, we'd need to support this manner of extension feature
in version 1.0.

Comments encouraged.

Cheers,

Chris