RE: State Alignment and Standard Signals

Steve:

State alignment requires reliable messaging but reliable messaging is
not a guaranty of state alignment as received messages could be
(objectively) un-understandable or unattended for. For me a measure of
success is to allow precisely enabling protocol substitution (both at
the document format) and protocol choreography level for any given
choreography. Because, as you pointed out, this is expected to vary upon
domains or QoS.

Jean-Jacques

-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Steve Ross-Talbot
Sent: Tuesday, July 20, 2004 9:34 AM
To: Anders W. Tell
Cc: Monica J. Martin; tony.fletcher@choreology.com;
kohei@dcs.qmul.ac.uk; Robin.Milner@cl.cam.ac.uk;
david.burdett@commerceone.com; yoshida@doc.ic.ac.uk;
public-ws-chor@w3.org
Subject: Re: State Alignment and Standard Signals


Doesn't all of this rely on some transport, which will have appropriate 
protocols, that ensures messages are delivered. Clearly this only 
provides guarantees of delivery, as I think is explained below. It does 
not guarantee that the application receiving a message processed it in 
any way. So what would be needed is a "business" message that makes the 
current state of the recipient visible to the sender. The way in which 
this could be done is to use some business relevant messages that form 
a protocol - an understanding if you will.

It does not require that WS-CDL defines these named message types since 
they may be different in different domains. I'm sure that FIXML handles 
this but their approach (their business protocol) is not applicable 
everywhere. It is imbued with their own semantics for a start and so is 
not portable across domains of applicability.

I guess the question that remains to be answered is "why have built-in 
named message types given issues of domain applicability?"

Hence my previous email on ontologies.

Cheers

Steve T

On 20 Jul 2004, at 17:23, Anders W. Tell wrote:

>
> Monica J. Martin wrote:
>
>>> Tell: ......Note: State alignment is not nessessary condition for a 
>>> data message to be legally relevant, its happens anyway.
>>
>> mm1: Can you please explain in further detail.  It may be legally 
>> relevant, whether it is legally enforceable, provides confidence and 
>> is binding are other matters IMHO. Thanks.
>
> Im not sure what to explain. If a speaker talks to a crowd there may 
> be now confirmation that all words has been received. If a sender 
> sends an email to a court or an application there may be no 
> conformation comming back and if the email actually reached the 
> intended addressee if will be recorded.
>
> With regards to enforceable a repudiation example may be of interest.
>
> If a originator sends a data message to an indented addressee but the 
> addressee claims that he didnt get the message.
>
> a) If the sender gets access to the receivers infoprmation system , 
> through court order or otherwise, and finds an exact replica of the 
> data message then it will be difficult to continue to claim that the 
> data message wasnt received.
> b) If in a automated environment a Receipt data message is sent from 
> the addresse back to originator with signature, ref to data message, 
> date, etc. it will be difficult to claim that the data message was 
> received. May the addressee can claim that the signature key was 
> stolen and it was resonable that the originator should have know about

> the theft.
> c) If an intelligent firewall stores all incomming data messages for 
> future reference and also does a XML Schema validation on the payload 
> then this log may be used to claim that the data message was received.
> d) ebXML MessageService Handler signed <Acknowledge> SOAP header may 
> be used to claims Reach.
>
> One important aspect is that it is Not resonable that a sender should 
> care about or be responsible for how a receiver has constructed its 
> information system and in case c) if the data message is lost after 
> the firewall then the reception failed under the recivers care.
>
> If a reciever has data message (reach event occured) and waits to send

> a ReciptAck until a deadline of some kind has passed then which is the

> most resonable outcome ..?
> 1. data message reached the indended addressee and it should be 
> counted as a "valid" data message
> 2. Reciept Ack was never sent in time so the data message should be 
> counted as not have been sent.
>
>
> thanks
> /anders

Received on Thursday, 22 July 2004 14:54:29 UTC