OASIS ebXML Messaging Services TC

[ebxml-msg] RE: Public usage scenario documents

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

    Posted 05-28-2002 09:30
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ebxml-msg message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


    
    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.
    
    
    
    
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


    Powered by eList eXpress LLC