- From: Steve Ross-Talbot <steve@enigmatec.net>
- Date: Tue, 6 Jul 2004 18:33:00 +0100
- To: <david.burdett@commerceone.com>
- Cc: <opensource@toolsmiths.se>, <distobj@acm.org>, <jeanjadu@Attachmate.com>, <public-ws-chor@w3.org>
There is certainly nothing to prevent you from contributing on the mailing list as indeed you are already. On 6 Jul 2004, at 17:26, <david.burdett@commerceone.com> wrote: > JJ > >>> I would warn against cheap hacks that would range from saying HTTP >>> 2XX > is enough, to one signal fits all.<< > > I agree, which means we need multiple signals, where each has well > defined semantics. > > Although I can't speak for the whole group, I think that defining > specific signals with rules on how/when to use them is a good idea. > > The question is which signals do we need? > > I know I don't have the background to do the work out which ones. What > we need is volunteers as I mentioned in my last email ;) > > So how about ... > > You and/or Anders offering to specify the signals required and how > they could fit in CDL, if the group agrees to *favorably* consider > whatever proposals you suggest? > > Thoughts? > > David > > -----Original Message----- > From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] > Sent: Tuesday, July 06, 2004 8:08 AM > To: Burdett, David; opensource@toolsmiths.se; public-ws-chor@w3.org > Cc: steve@enigmatec.net; distobj@acm.org > Subject: RE: CDL Challenge > > > Non-repudiation is not equal to state alignment. > > You may want to create a signal that includes both if this is what > happens all the time (you might also argue that the non-repudiation > signal can be generated very fast and is generally part of the response > to the incoming message) while state-alignment may take anywhere from > seconds to hours to be processed (e.g. nightly batch feed of the daily > messages to a system), > > But in general you may want to achieve state alignment without > non-repudiation as they are two very distinct concepts. This is why > multiple protocols may exist. The important factor is that there is a > way to make these protocols explicit and establish relationship with > the > choreography definition, this will guaranty a very good level of > interoperability. > > I would warn against cheap hacks that would range from saying HTTP 2XX > is enough, to one signal fits all. > > JJ- > > > > -----Original Message----- > From: david.burdett@commerceone.com > [mailto:david.burdett@commerceone.com] > Sent: Tuesday, July 06, 2004 7:25 AM > To: opensource@toolsmiths.se; public-ws-chor@w3.org > Cc: steve@enigmatec.net; distobj@acm.org > Subject: RE: CDL Challenge > > > Anders > > I agree with you that defining how to do some "Acknowledgement of > Receipt" signal is a good idea. I'll respond to your email in broader > response to JJ around state alignment. > > David > > -----Original Message----- > From: Anders W. Tell [mailto:opensource@toolsmiths.se] > Sent: Sunday, June 06, 2004 2:01 AM > To: public-ws-chor@w3.org > Cc: Burdett, David; steve@enigmatec.net; distobj@acm.org > Subject: Re: CDL Challenge > > > A comment from a legal perspective which for obvious reasons is > important for global ecommerce. > > david.burdett@commerceone.com wrote: > >>>>> Nick any comments from you and/or David?<<< >>>>> >>>>> >> >> A few ... ;) >> >> The real question we need to answer is what should be the "primitives" > in CDL. For example all of the following *could be*: >> 1. A "one-way" fire & forget message >> 2. A "request-response" where a message is sent and a response should > be received >> 3. A "one-way reliable message" where a message is sent and resent > until an acknowledgement is received >> >> > <AWT> > (4) > I would like to add another primitive which is so importants that it is > mentioned in national, international LAW and in UN Recommendations 26 > and 31, The *Acknowledge of Receipt* signal. > This primitives purpose is to provide recognition and evidence that the > reach-event has occured at indended addressee. With or without > signature > > it provide a degree of non-repudiation. > > A sideeffect which is important for business automation purposes is > that > > it increases the probability that the sender and indended addresses has > the same information and is confident that they do. A technologist may > view it as a form of state-alignment. > > This primitive is similar to 3 but not the same and it has a direct > relation to business and legal considerations. > </AWT> > >> The disadvantage of having several primitives are primarily around: > deciding which ones to include, knowing that we have included the ones > we "need" to, and allowing additional primitives to be added over time. >> >> > <AWT> > The above primitive wont go away and change anytime soon since it > depends on LAW. > > For US it is also part of the UNIFORM ELECTRONIC TRANSACTIONS ACT > (1999) > </AWT> > > Thanks > /anders
Received on Tuesday, 6 July 2004 13:37:10 UTC