Re: missing(?) header element

[Martin W Sachs/Watson/IBM <mwsachs@us.ibm.com>]

Why would not application headers be simply part of the application payload
as far as the messaging service is concerned?  One answer might be that the
messaging service (or some plug-in in the application services layer) might
have to look at information in these headers before the payload is passed
to the application.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Christopher Ferris - XTC Advanced Development <chris.ferris@east.sun.com>
@xtacy.East.Sun.COM on 11/16/2000 02:03:09 PM

Please respond to ebxml transport <ebxml-transport@lists.ebxml.org>

Sent by:  cferris@xtacy.East.Sun.COM


To:   ebxml transport <ebxml-transport@lists.ebxml.org>
cc:
Subject:  Re: missing(?) header element



As a follow-up to today's discussion on this topic
the following issues were raised:

- we need to determine from the other verticals
  (e.g. RosettaNet, OTA, EDI/INT, Ariba, others)
  whether this feature is used extensively, and
  to what end (e.g. does it trickle down to the
  application layer? via what mechanism is this
  ensured?)?
AI: anyone with specific knowledge or experience
  in this regard should speak up! ;-) It would
  also be useful if we could have specific feedback
  from members participating in other verticals
  (such as RosettaNet or OTA) as to whether they
  see this feature as important/critical to
  acceptance/adoption of ebXML should that question
  be on the table.

- we would need to provide specific language which
  outlines its purpose and intent. Does it apply
  exclusively to the MSH or does it apply to the
  application? Is it used only by convention between
  two parties engaged in establishing a production
  exchange, each agreeing to well defined ground-rules
  for its use? Is its purpose exclusively limited to
  "testing" the MSH configuration/handling of a
  given message (e.g. it SHALL NOT be forwarded
  to application-level routing...)

- John Ibbotson and others suggested that a specific
  MSH Service/Action of MSH/PING might satisfy the
  requirements better. This would fall into the
  work (TBD) of defining an MSH "Service Interface"
  with specific Service/Action pairs which have
  specific behavior (e.g. expected response, exceptions,
  etc.) defined.

- Scott H and others suggested that without a
  clearly defined architecture for incorporating
  "application-level" headers in the ebXML packaging
  we are essentially left with placing this sort
  of header element within the body of the ebXMLHeader.

- Chris re-raised the issue of adding in an explicit
  extension mechanism to the ebXML headers to allow for
  "application-level" headers such as test/production flag,
  security/session context information, transaction context
  information (ie. XAML) and others.

  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 actor attributes defined.

- Maryann raised the issue of security implications
  for a test/production indicator as well as possible
  concerns for XML Signature handling of ebXML headers
  if an arbitrary extension mechanism were defined.

clearly, the issue is still not resolved and there
is not yet consensus beyond the fact that the proposed
functionality seems to have some potential merit
but that the means of conveying this feature needs
more work and more thought.

Have I captured the highlights of the discussion
and issues thus far?

Cheers,

Chris

--
                               Christopher Ferris
    _/_/_/_/ _/    _/ _/    _/ Sr Staff Engineer - XTC Advanced Development
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903