[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: security and timing parameters
Karsten et al .. I may not be using the defintion concepts in the correct context, my appology, but from Bob's defintions of "timeToAcknowledgeReceipt and timeToAcknowledgeAcceptance" as they pertain to business operating activities, these together with security (which at least I'm defining the concept as who I as the sender authorize to the receiver is allowed to perform a unit of work for me) are essential elements of and core to the fabric of business. If you would like specific business examples of common business proecess that occur around the world today, I'd be more than happy to list and detail out a few. I can't imagine letting a supplier respond back to my puchase order ... 'whenever' in a direct customer-supplier relationship (ex. drop ship customer orders off the Internet), or as an intermediary allowing anyone to do work on my behalf at a vendor site without exercising some degree of reasonable business limitations on the vendor in a customer-intermediary-vendor relationship chain where the intermediary is servicing the customer (ex freight forwarding in global transport). Thanks Dave > -----Original Message----- > From: Bob Haugen [mailto:linkage@interaccess.com] > Sent: Thursday, December 28, 2000 10:55 AM > To: 'ebxml-bp@lists.ebxml.org' > Subject: RE: security and timing parameters > > > Karsten and all, > > Is this a test to see if we are paying attention? > (Note: this is the only parameter assignment I have payed > attention to so far.) > > <KR> > NOTE: I am not putting timeToAcknowledgeReceipt and > timeToAcknowledgeAcceptance > into RequestingBusinessActivity even though they were in the > BusinessActivity superclass. They are only relevant to > the responding activity. > I actually think TimeToPerform is not relevent to the > requestor either, but leaving > it here for now. > </KR> > > My reading of the spec indicates that both Responding and > Requesting BusinessActivities use those parameters in > different ways. The transaction is a unit of work from the > viewpoint of the Requesting activity; therefore, if the time > parameters are exceeded (that is, the required ack or > document does not arrive by the appointed time), the > Requesting activity can abort the transaction. > > From the description of TimeToAcknowlegeReceipt: > "A sending partner must retry a commercial transaction if necessary > or must send notification of failed business control > (possibly revoking > a contractual offer) if a responding partner does not verify properly > receipt of a business document request within the agreed time > period. > The time to acknowledge receipt is the duration from the time > a business > document request is sent by a requesting partner until the time a > verification of receipt is "properly received" by the > requesting business > partner. This verification of receipt is an audit-able > business signal and > is instrumental in contractual obligation transfer during a contract > formation process (e.g. offer/accept)." > > -Bob Haugen >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC