OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC