Re: CDL Challenge

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