RE: CDL Challenge

Anders

*If* we do decide to define signals, I think we should just define: a) its semantics, b) a standard message type and c) standard states to correspond with the receipt (or not) of of the signals. I don't think we should define a standard representation for the signals as this can vary.

David

-----Original Message-----
From: Anders W. Tell [mailto:opensource@toolsmiths.se]
Sent: Sunday, July 18, 2004 5:54 AM
To: Burdett, David
Cc: public-ws-chor@w3.org; steve@enigmatec.net; distobj@acm.org
Subject: Re: CDL Challenge


david.burdett@commerceone.com wrote:

> 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?
>  
>

I have to keep read the CDL spec but Im interested in keeping a dialog 
with the team. :)

For now I would like to bring forward two type signals
1. Receipt acknowledgement
     with Signature
     with a list of objective *criterias* that the sender of the reciept 
says has been verified at the time of reach-event.

2. Notice (good faith)
    a reciver that is expecting a data message could ask the sender  
what has happended to the message.
   (its not the same a status request since the message id is now known.)
    (maybe this good faith signal should be a data message since a reply 
may be expected but
    it should be part of any frameworks basic set of "administrative 
data messages")

The early rejection message (acceptance ack) fits better a data message 
than a signal.

cheers
/anders

Received on Sunday, 18 July 2004 20:45:52 UTC