RE: ebXML header extension mechanism proposal

["Burdett, David" <david.burdett@commerceone.com>]

I think this is a good idea but I think I would go for "mustUnderstand"
rather than "mayIgnore". 

On another point in the current DTD attributes are Upper Camel case rather
than lower camel case (e.g. DeliverySemantics) we need to be consistent.

David

-----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