Re: missing(?) header element

[Scott Hinkelman/Austin/IBM <srh@us.ibm.com>]

The issue revolves around a design of concern seperation taking into
account
security ramifications and visibilty/responsibility of such *conceptual*
(unspecified,
as we are only specifying a serialization format) layers as a message
service vrs
an application. Even if this sort of entity is the responsibility of the
conceptual application
layer, we should explicitly accomodate it and not think it should be part
of the payload.
One of the value propositions of ebXML is to consistently facilitate items
for vertical
efforts that are addressing the same issues inconsistently, of which this
is one, almost
regardless of it's exact semantics. So, currently there is no other place
to put it except
in the header. It is certainly is something that needs exposure to the
conceptual
application layer. Are the ramifications to this? Do we need another
"place"?

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Martin W Sachs/Watson/IBM@IBMUS on 11/16/2000 01:55:18 PM

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




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