Re: [ebxml-msg] Business (Legal) analysis of ebMS 3.0

["Anders W. Tell" <anderst@toolsmiths.se>]

Ian,

>	Jeff Turpin is working on the spec at the moment and a some major additions and changes are likely to be included in the next few weeks, completion of the Reliability section (inclusion of a pull profile) and changes to use SOAP 1.1 not 1.2.  
>
Thanks, Looking forward to its release.

> <>The question I have is what level of receipt acknowledgements are 
> you looking at as this will be a many layered protocol, the transport 
> layer could be acknowledging, the Reliability component may be 
> acknowledging the ebMS could be acknowledging ( we have not completed 
> this section yet it may not be needed, we need to complete the 
> Reliability section first), the application/business level may be 
> acknowledging. 

In this study any layering has been removed, in other words I look at 
the total number of message needed to transport one "data message" 
between two or mor parties. In a business and legal sense layering has 
little or no meaning, they fill primarily a function of separation of 
concerns.

>If your concern is the potential number of acknowledgements messages that could be sent in the worst case scenario it could be very many, this is the problem of having a flexible system that has many level of reliability.
>  
>
Im not so much concerned with the effeciency aspect of too many mesage. 
The aspects Im looking at in this study are more legal consideration and 
relationship to Trading Partner Agreements

>	The issue may be having applications use what is appropriate, if they can handle the retry etc. they do not need the reliable functionality of the lower levels, but they are available.  If people want to make the process very complex and turn on all the possible levels they can and should be allowed to do this as we do not know of their reasons.  I think as long as we explain in the specification(s) what is happening it should be up to the message handler/system vendors and users to configure the runtime implementations as they wish as long as the retain interoperability to support the acknowledgement level the need. 
>  
>
In some sense I agree, parties can agree on technical details and their 
effects.

However there are aspects that one cannot ignore and the concepts of 
dispatch and reach are two. If a party "has access to a data message" 
then the data message is available for receiver to act upon., The time 
when this occurs is important and must be differentiated from time of 
dispatch of acknowledgement. The first time an indication of receipt 
reaches the originator the originator knows that the message was 
properly received. If the originator get HTTP 2xx its an Ack but its an 
Ack with poor non-repudiation properties. A signed ack would be better 
but does not change the *fact* that the message was received. If the 
reciver disputes that he got the message then the originator may claim 
access to recivers information system and if the data message is found 
there the ruling will most likelly be that the data  message was 
properly recieved.

These are prime concerns for a business protocol but may not be so 
important for a protocol used for business purposes.

/anders

>
>Ian Jones
>Chair OASIS ebXML Messaging Services TC 
>
>-----Original Message-----
>From: Anders W. Tell [mailto:anderst@toolsmiths.se]
>Sent: 19 November 2004 08:07
>To: ebxml-msg@lists.oasis-open.org
>Subject: [ebxml-msg] Business (Legal) analysis of ebMS 3.0
>
>
>Hi,
>
>Im doing an analysis of some protocols from a business (and legal) 
>requirements point of view. ebMS is one of analysed protocols. One area 
>of concern is Acknowledge of Receipt funcitonality and rules of 
>evidence. Looking at the older may 3.0 draft it seems as if ebMS 
>proposes, for some patterns, acknowledgements 5+1+1 times which seems to 
>be rather many.
>
>Could someone pointme to the latest ebMS spec so I have the latest info 
>available?
>
>I would also appreciate if a clarification could be given if  ebMS 
>includes the ebMS Acknowledge (intermadiary and party) found in ebMS 2.0?
>
>thanks
>/anders
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/members/leave_workgroup.php.
>
>
>
>  
>