Revised ebMS WP attached.

[David RR Webber - XML ebusiness <Gnosis_@compuserve.com>]

Team,

We received the following comments, which the attached new copy
addresses.   I really, really, think this version is now ready to go out!

Unless anyone has any last minute tinkering - I'm planning to do
the final copy on Wednesday and ship that out to Carol and Dee so
they can post it to the site and do the notice in XML.org

Thanks, DW.
===============================================================
> Document lacks use cases or the appropriate deployment scenarios. It
> is not true that each and every
> application requires direct API access to a messaging subsystem nor
> that the application requires that subsystem to implement all of the
> relevant protocols.

>>> I enhanced the wording of the Introduction - BTW - I disagree with
this 'take'.  We provide lots of detail of deployment scenarios, I think
the reader just has a knee-jerk reaction to Figure 1, and maybe an
older copy of the doc'.
<<<

> Table 2.1: Why is S/MIME listed for "encryption support on envelope"
> and RSA and PGP (which are not in any way similar) are listed for "...
> on payload"?  RSA cyphers and hashes may be used together with either
> S/MIME or PGP (which operate at the same level and are similar) to
> encrypt either payloads or headers (or both).

>>>> Fixed.  This is Table 3.1 - so suspect comments were not against
latest copy of document...which probably also explains 'use case' comment.
Hmmm.  These separations are part of the original ebMS design.  Basically
these are restrictions more of the SOAP model than anything else.  
Conceptually the comments are right - but in practice SOAP limits your 
choices here, so I've made it clear this relates to http/SOAP model.
<<<

>
> Table 2.2 does not make it clear the SOAP column references use of
> this protocol completely alone, instead of (say) when combined with
> WS-Reliability or ebXML Messaging.  The high score for robust delivery
> protocol and dial-in modem is perplexing at best.

>>> Fixed.  SOAP is simple only server.  I disagree with assessment
of VAN - dedicated lines plus sftp - that's the gold mark here!  Dial-in 
modem is not as insecure as he seems to think, delivery will only 
complete when verified, and re-start recovery works, along with
encryption at modem level.  I noted this in the blurb on Dial-in BBS.
<<<
>
> Table 2.3 maligns SOAP without justification.  Apache is not the
> single source provider of SOAP solutions,
> as implied on the first line!
  
>>> So OK - I picked some categories that don't do SOAP any favours!
Good to get confirmation!  Bottom line is that if your 'send' via SOAP
dies,
you have little or no detection / recovery - that's what ebMS is designed 
to fix!!  Simple truth - everyone starts with the Apache codeset - even if 
they then re-write / extend that...and in case of our study audience 
most people will use the free version ahead of buying something. And
if you pick that approach - its a DIY project, so my assessments 
stand here.  If you start looking at tools that enhance SOAP - then you
are into ebMS needs - and its not our job here to say what a 
preferred webservice should look like - just to point out that the 
"pitch" of "all you need is SOAP and its free", may leave you a 
little short.... so ebMS is the solid choice here today - certified, 
shipping and proven.
<<<

WP - Messaging-Interchange Requirements 051803.doc