Re: [ebxml-mktg-sc] Revised ebMS WP attached.

[Alan Kotok <akotok@disa.org>]

David, et al.

Good job.  I got my comments in on an earlier draft.

Just a little reminder that this group is a joint OASIS/CEFACT endeavor, 
and we would like to have the announcement for the DISA Daily Wire at the 
same time as XML.Org.

Alan Kotok
Editor, < E-Business*Standards*Today />
http://www.disa.org/dailywire/
Data Interchange Standards Association
akotok@disa.org
+1 703-518-4174



At 03:20 PM 5/18/03 -0400, you wrote:
>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.
><<<