RE: trp and soap

[Robert Fox <robertf@softshare.com>]

To further hint at the answer to this question... the ebXMLHeader element is
effectively replaced with a SOAP message... the SOAP message contains:

SOAP Envelope which contains 2 parts:
	1 - A SOAP Header, which is optional by SOAP specs, but mandatory by
our specs
	2 - A SOAP Body, which is mandatory by SOAP specs

we have divided the elements in the ebXMLHeader element to fall into these 2
sections (SOAP HEADER, SOAP BODY)... we are proposing to include elements
that pertain to the Header in the Header section, and those that tie to the
payload in the SOAP BODY... PAYLOAD containers remain as is in
attachments(s).

The proposed elements that we discussed for HEADER/BODY in the SOAP message
are as follows:

SOAP-HEADER:
	MessageHeader (formerly Header)
	TraceRoute (formerly RoutingHeaderList)
	Signature
SOAP-BODY:
	Manifest
	StatusData
	ErrorList (inside a SOAP-FAULT element)
	Acknowledgement

Hopefully, when the first edit is released for review, this will all make
total sense...

Cheers!

Robert Fox
Director of Product Development
Softshare
EM: robertf@softshare.com
PH:(805) 899-2366
FX: (805) 882-2599 






-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Tuesday, February 20, 2001 9:25 AM
To: Phil Zimmerman
Cc: ebXML Transport (E-mail)
Subject: Re: trp and soap


Yes, all of the ebXML header elements are with
the exception of ApplicationHeaders which has been
(or will be) removed.

Cheers,

Chris
Phil Zimmerman wrote:
> 
> Rik,
> 
> Am I correct in assuming (carefully using this term ;)) that the
ebXMLHeader will still
> contain the manifest which is missing in SOAP with attachments?
> 
> -Phil
> 
> Rik Drummond wrote:
> 
> >  As you are aware, ebXML transport, routing and packaging was approached
by
> > the workgroup in w3c who would become the xml protocol workgroup in may
2000
> > to discuss convergence between soap and ebXML transport.        Soon
afterwards
> > ebXML assigned dick brooks of 8760 to be the official trp representative
on
> > the xp workgroup. Several intellectual property issues existed with soap
> > 1.0, 1.1 and soap with attachments that precluded trp from using soap.
> > Additionally while soap 1.0 was not usable for ebXML trp because it
lacked
> > the ability to move any type of digital data soap 1.1 and soap with
> > attachment added capabilities very technically similar to ebXML trp
message
> > structure in the subsequent versions. During our Vancouver meeting a
highly
> > qualified team representing soap and trp evaluated the possibilities of
trp
> > using soap. The investigation showed that to implement trp in soap would
> > require no logic changes or changes to the meaning or the existing trp
data
> > elements in the header - except in one ?possible? instance the handling
of
> > error status.
> >
> > While this is somewhat of a dangerous course this late in the
development of
> > the specification we felt the benefit far outweigh the dangers. Benefits
> > such as fewer standards to support by vendors, more investment by
software
> > vendors in ebXML mhs because of the alignment of soap and mhs and less
> > market confusion and it will have a better change of becoming the vendor
> > neutral inter-exchange, SME and le transport of choice.
> >
> > We presented our conclusions to the ebXML steering group on Tuesday and
said
> > we could technically include soap in the ebXML trp specification under
the
> > following conditions:
> > -       we were given an additional 4 week to complete the spec -until
march 19
> > -       we were allocated key full time resources from our team to the
project
> > until march 19
> > -       we were allocated key soap experts until march 19
> > -       all intellectual property issues were resolved by feb 16
> > -       we would be allowed to not address any outstanding technical
comments
> >         made on the existing version .93 message handling services
specification -
> > they
> >         would have to be resubmitted against the next version after soap
was
> > included - if they still existed
> > -       Finally, even though this is a major cosmetic change to the
spec, not a
> >         logic or header element change, we would only be required to go
through one
> >         review cycle before plenary approval.
> > -       The trp team approved the effort
> >
> > As of feburary 16, 2001 all condition have been met.
> >
> > We are now diverting all resources to aligning soap and ebXML packaging
for
> > final approval of this modified spec in Vienna
> >
> > With this in mind and to accomplish these aggressive goals I suggest a
few
> > rules on how we manage the spec in our work group.
> > -       we will not address any not hitherto include functionality in
this spec
> > -       we will not clutter the email list with topics which do not
directly
> > pertain to accomplish this goal
> > -       Ian jones has been assigned by the trp group as proctor to
curtail any
> > discussions not following the above two points
> >
> > The work effort will progress as follows:
> > -       three or four expert form trp and soap will convert the spec to
> > incorporate soap 1.1 and soap with attachments
> > -       once that has happened we will assign two readers to look for
technical
> > issues or introduced errors
> > -       it will be given to our trp editing team for editing
> > -       it will be released to the list for review and comments
> > -       final edits will be incorporated from list discussion
> > -       the trp group will vote on whether or not to release it for
ebXML wide
> > review
> > -       submitted to qr team on march 19 or earlier
> > -       release for ebXML wide review soon after
> > -       incorporate comments from review
> > -       plenary vote.
> >
> > To facilitate the specification passing qr team review I have asked the
qr
> > formally assign a person to continuously trace progress over the weeks
to
> > ensure that any issues that they have, and we can address, or addressed
> > before qr review.
> >
> > If you have questions please send me email via the trp list serv.
> >
> > Best regards, rik
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org