trp and soap

[Rik Drummond <rvd2@worldnet.att.net>]

 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