RE: ebXML header extension mechanism proposal

["Adams, Robert" <robert.adams@intel.com>]

I would like to second Chris' comments.  Last week I sent a proposal for a
per document extension element (added to the DocumentReference element
inside Manifest) but I also think Chris' idea of a per package extension is
necessary.

Allowing extensibility for security credentials, per document detailed
information, and per package identification information that is
infrastructure specific or package specific allows testing and enhancement.

Requiring the extension to be name space qualified with an optional
"mustUnderstand" would make the extensions invisible to receivers that
didn't know about them.  The schema could look like:
	<element name="Extension">
		<complexType>
			<sequence>
				<any namespace="##other"
processContents="skip" />
			</sequence>
			<attribute name="mustUnderstand" type="boolean"
				use="optional" value="true" />
		</complexType>
	</element>


-- Robert Adams

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Thursday, November 30, 2000 6:03 AM
To: ebxml-transport@lists.ebxml.org
Subject: ebXML header extension mechanism proposal


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