OASIS ebXML Messaging Services TC

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

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

    Posted 05-28-2002 12:37
     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