RE: missing(?) header element

[Stefano POGLIANI <stefano.pogliani@sun.com>]

At this point, it seems to me that the safest way of dealing would be 
to use the "Ping" approach that was proposed somewhere in a previous mail.

It depends on what the goal is:

	- if the goal is the one originally mentioned by Chris:

		> The purpose of this element (or attribute as the case may
		> be) is to enable parties to exchange messages prior to
		> actually engaging in e-business, to ensure that their
		> systems are prepared to correctly handle the messages
		> they send eachother.

	  then I think that this is an MSH issue and, for that reason, it
	  is of no-use to send any "application meaningful" payload along
	  with the message.
	  The MSH should be able to use the special type of message (PING ?)
	  as a way to test its readiness to engage.

	- if the goal is to "test" the application layer, than this should
	  be completely transparent to the MSH, IMHO.
	  In this case, the "Test" should be something semantically 
	  understood by the application layer and, thus, part of the payload.

	  The MSH should see this as a message to be passed to the Application
	  Layer, as just (almost) any other message. It will be the 
	  App layer to understand that this message has a "particular" meaning
	  and to treat it accordingly.

	  Again, the Choreography could specify that this "special" message
	  could be received at some very point of the chain of messages and
	  should be trated in some way.

/Stefano


> -----Original Message-----
> From: Henry Lowe [mailto:hlowe@omg.org]
> Sent: Friday, November 17, 2000 3:24 PM
> To: ebxml transport
> Subject: Re: missing(?) header element
> 
> 
> Yep, I agree with Marty -- define an optional application headers 
> MIME part for the payload and led the app (BP?) folk decide what 
> goes in there.  (OK, that's a bit more than what Marty said :-)
> Don't get MS headers munged (good OED word?) by sticking application 
> stuff in them!!!!
> 
> Best regards,
> Henry
> --------------------
> At 02:55 PM 11/16/2000 -0500, Martin W Sachs/Watson/IBM wrote:
> >
> >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
> >
> >
> >
> 
>