MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [ebxml-msg] RE: Public usage scenario documents
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/
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC