Re: [ebxml-msg] RE: Public usage scenario documents

[Duane Nickull <duane@xmlglobal.com>]

Marty:

Please try

david.webber@xmlglobal.com

not the compuserve address.  Compuserve has a relatively small mailbox
size - not nearly enough for the prolific David RR  

;-)

Duane

Martin W Sachs wrote:
> 
> My reply to David Webber was rejected by ebtwg@lists.ebtwg.org  with the
> following error message:
> 
>      550 Mailbox unavailable: This site may not be used as a relay agent.
> 
> I don't know whether this is a temporary or "permanent" problem.  Someone
> who knows where to report problems might want to forward this to the
> appropriate place.
> 
> 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
> *************************************************************************************
> 
> 
>                       David RR Webber -
>                       XMLGlobal                To:       Martin W Sachs/Watson/IBM@IBMUS
>                       <Gnosis_@compuser        cc:       "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>,
>                       ve.com>                   ebxml-msg@lists.oasis-open.org, Randy Clark <Randy.Clark@bakerhughes.com>,
>                                                 "'bhaugen'" <linkage@interaccess.com>, eBTWG List <ebtwg@lists.ebtwg.org>,
>                       05/28/2002 12:14          "'Duane Nickull'" <duane@xmlglobal.com>, Christopher Ferris
>                       AM                        <chris.ferris@sun.com>
>                                                Subject:  RE: Public usage scenario documents
> 
> 
> 
> 
> Message text written by Martin W Sachs
> >     Both parties to the message exchange MUST persist enough state to
> allow recovery and getting back in sync. Specific state variables must
>      be prescribed.  They are at least those variables needed to restore
> the state of the transaction and conversation after system recovery, such
>      as the conversation ID, CPA Id, service, action, and perhaps other
> parts of the message header.
> 
>      Timeouts and retries, as prescribed in the MSG spec, are not
> sufficient to cover system failures since the failure could last a very
> long time.
> <<<<<<<<<<<<<<<<<<<<<<<
> 
> Marty,
> 
> There appears to me to be no big surprise there.   I would say this was
> EDI 101 - and that we hardly need things in the spec' which teach
> people how to build applications systems.
> 
> People who know how to build product will include these feature sets
> and augment them according to their customer base requirements.
> So we do not need to teach this - and worse - it potentially forces
> people to build this in - even if their use case / customer model
> can use a lesser level of functionality quite happily.
> 
> We have avoided this with Registry for example.
> 
> If you are building a reliable messaging product - you are going to
> have a all manner of features in it over and above - like being able
> to check that the confirmation was signed by someone with
> a wristwatch on their left arm, et al/
> 
> Or worse - what about hardware level verification of tamperproof
> retention for authentication in a five year time frame?   At some point
> you have to quit and know - this is outside our scope.
> 
> Let's not confuse functional level detail - with technical specifications.
> 
> Cheers, DW.
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

-- 
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/