Re: State Alignment and Standard Signals

Not really , what you have to do in situation of building an information 
systems or in case of dispute, is to look at the composite situation. 
The "layers" themselves mean very little if anything. IMO the layers 
serve a architectural tools for separation of concerns but in a 
business/legal setting they all merge together in a wholistic 
information system.

It has to do with Riskallocation, which party is responsible for handle 
a message from which time and onwards. There is always two parties (or 
more) that exchange information and some information,documents are very 
important such as offers, job application, acceptance, court filings and 
the LAW specifies rules which information systems must comply to.

Another example:
* One party does a check in their database of account numbers per 
accepted business partner.
* A new parter sends an "important" document and the reciver sends a 
Recipt Ack but later sends a rejection message specifying that the 
originator was not in database and/or the account no was valid.
* The originator/sender is surprised since they are a new partner. After 
two working days and a weekend the sender has convinved the reciver that 
is was their database that was not updated with the senders information 
and account number.
* The sender resends the document but which date should be recorded as 
Reach/reception date?
    In most situations that first date, before the weekend, is the date 
to record.

Here the outcome is not: success/failure with rejection semantics but 
Dispute which is later resolved.

If one looks a the fine print one can see that is beneficial to in a 
protocol/collaboration contract to recognize that there are two parties 
(or more) in a interaction and that there are various rules for when/how 
a data message has been Dispatched, and when the data message has 
Reached its intended addressee. The national LAWs that specifies this 
are designed (attempts to be) for all types of technologies, old, new 
and future unknown.

Another Reach example:
In many court procedings the date attached to an incomming document is 
that date when for example a janitor takes a white envelope without 
looking at its content (reach the desk). If the janitor the forwards the 
envelope the next day, its still the first data that is valid.

What we are trying to do is to emphasise that Dispatch-Reach Events 
(specification) are vital in any protocot that tries to organize the 
exchange of two or more data message between information systems. So is 
the difference between instantaneous (webservices, chat...) and 
non-instantaneous (email, store forward, pull,...) since it drives that 
collaboration through the calculation of timeout.

Thanks
/anders

Steve Ross-Talbot wrote:

>
> 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 05:56:53 UTC