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