RE: CDL Challenge

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 12:26:44 UTC