Re: [ebxml-msg] Re: ebMS_v1.091.zip

[Christopher Ferris <chris.ferris@sun.com>]

Shimamura-san,

Please see my comments below.

Cheers,

Chris

SHIMAMURA Masayoshi wrote:

> David, 
> 
> Thank you for creating the revision. Here is my comment.
> 
> o Adding status attribute to ConversationId element
>   I hope we reaches consensus for this issue and my suggestions below
>   are included in the specification:
>   
>     <http://lists.oasis-open.org/archives/ebxml-msg/200112/msg00005.html>
> 


I don't see the need for this. If a message should arrive after
the conversation has ended, then one of two things will apply:
	- the TTL will have expired, thus the message can be
	discarded
	- the message will be detected as a duplicate of a
	previous message and will be handled accordingly

If a message arrives with a ConversationId which is (apparently)
unknown to the MSH, then it is treated as a new conversation.


> o Clear definition of signed Acknowledgement Message
>   I hope signed Acknowledgement Message is defined clearly. See
> 
>     <http://lists.oasis-open.org/archives/ebxml-msg/200112/msg00165.html>
> 
> o Conditions for MessageOrder
>   I hope we reaches consensus for this issue and my suggestions for
>   section 10 below are included:
>   
>     <http://lists.oasis-open.org/archives/ebxml-msg/200112/msg00080.html>
> 
> o Invalid description about MessageId
>   Please include my suggestion below. I believe we don't need much
>   discussion for this issue. See:
> 
>     <http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00313.html>
>   


Probably not, but why say anything other than that the string
representing the MessageId value be unique within the set
of messages exchanged between the parties. I don't think that
we need to specify a particular format.


> o Error Handling
>   I except the suggestion below will be included soon by Doug's working.
>     
>   > Date: Thu, 29 Nov 2001 15:48:42 -0800
>   > From: Doug Bunting <dougb62@yahoo.com>
>   > Subject: Re: [ebxml-msg] Comments on the 1.09 about Error Handling
>   > To: ebxml-msg@lists.oasis-open.org
>   > Message-id: <010b01c17930$60b06a90$879712c0@immd>
>   ...
>   > * Replace the third paragraph of B.2.4 with words recognising that SOAP
>   > errors may come back synchronously (over HTTP) whether or not SyncReply was
>   > true.  In fact, the words from the SOAP specification should mean soap:Fault
>   > won't be returned asynchronously when using a synchronous communications
>   > protocol.  Our choice in this paragraph contravenes SOAP, we should just
>   > recognise the aspects of SOAP causing somewhat inconsistent "async over
>   > sync" behaviour.  I'm not even sure it's inconsistent from our point of
>   > view: SOAP is another communication protocol, like TCP/IP and we certainly
>   > expect many TCP/IP failures to occur synchronously.
> 
> 
> Regards, 
> 
> --
> SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
> TEL:+81-45-476-4590(ext.7128-4241)  FAX:+81-45-476-4726(ext.7128-6783)
> Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>