OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC