Re: T2: Reliable Messaging (point-to-point)

Sorry for the delayed response. I was tied up the last couple 
of days attending to some personal matters.

 

To answer Cait's original question about the Service and Action elements 
that should be used when a message containing a DeliveryReceipt element is to be 
sent not in conjunction with any business level reply, the following excerpt 
from the 1.0 spec clearly states:

If there are no errors in the message received and a DeliveryReceipt is being sent on its own, not as part 848

of message containing payload data, then the Service and 
Action MUST be set as follows: 849

· the Service element MUST be set to uri:www.ebXML.org/messageService/ 850

· the Action element MUST be set to DeliveryReceipt 851

Unfortunately, the above information is located in section 8.4.7.1 
deliveyReceiptRequested attribute, rather than in section 8.14 DeliveryReceipt 
element.

 

I believe the spec is currently quite specific about the Service and Action 
elements to use when Acknowledgement, DeliveryReceipt, Error, StatusRequest, 
StatusResponse, and Ping elements are sent on their own (not in conjunction with 
business payloads).

 

-Arvola

 

-----Original Message-----
From: Burdett, David 
<>
To: 
'Dr Crawford' <>;  
<>
Date: 
Monday, August 06, 2001 6:39 PM
Subject: RE: T2: Reliable Messaging 
(point-to-point)

>I think that this is a bug in the spec.
>

 

>To solve this problem I think we should include in every message that 
is
>sent, an identifier for Service that is sending it. You can then use 
this
>Service when returning a message if there is no business process 
specific
>one to use instead. You would then use the Action element to 
identify why
>the message is being sent.
>
>If we make this 
approach the rule for returning errors, for example, then it
>fixes the 
problem that a MSH does not know which application it should
>notify if 
the original message was not persisted (which it shouldn't be if
>it was 
not sent reliably).
>
>I also think we should follow the same 
approach for the Message Status and
>Ping transactions for the same 
reasons.
>
>Thoughts?
>
>David
>
>-----Original 
Message-----
>From: Dr Crawford [mailto:]
>Sent: 
Monday, August 06, 2001 8:11 AM
>To: 
>Subject: 
T2: Reliable Messaging (point-to-point)
>
>
>
>
>I 
have a comments/questions regarding POINT-TO-POINT reliable 
messaging
>implementation for ebXML MS 1.0.
>
>First, lets 
assume that Party A is sending a message reliably -- that 
the
>deliverySemantics have been set to OnceAndOnlyOnce 
and
>deliveryReceiptRequested to Unsigned (I don't think that 
Signed/Unsigned
>makes a difference for the example, actually) in the 
QualityOfService
>element in the MessageHeader.  I am sending this 
message w/out
>intermediaries, so I am not making use of the Via or 
Acknowledgment
>elements, although I am populating the TraceHeader element 
as appropriate.
>
>Now, Party B receives the message.  Now 
assume that there is NO REPLY from
>the application.  Party B is 
required to send an "Acknowledgement Message"
>(section 10.3.2) which at a 
minimum has a MessageData element with a
>RefToMessageId of the received 
message.  Since a deliveryReceipt is also
>requested, the MSH must 
also generate the DeliveryReceipt element in the
>ack message.  My 
question concerns the service and action elements of this
>ack.  
Clearly, as there is no business-level reply, the service and 
action
>should not reflect any business or application level service & 
action.  In
>section 10.3.3, the spec says that if an Acknowledgment 
element is being
>sent on its own then service MUST be set 
to:
>uri:www.ebxml.org/messageService and action MUST be set to 
Acknowledgment.
>What is the equivalent service/action for a 
DeliveryReceipt element being
>sent on its own?? (as set in the 
MessageHeader element for this ack
>message)??  Is this described in 
the CPP/BPSS since this is one of the
>"signals" that need to be processed 
by the MSH-application interface??
>
>What would happen if the 
deliveryReceiptRequested was false, but the
>semantics were set to 
OnceAndOnlyOnce??  The minimal acknowledgement
>required only a 
RefToMessageId within the MessageData element -- any
>guidelines as to 
what should be used in the Service and Action elements in
>the 
MessageHeader?
>
>In general, I think that the Reliable Messaging 
section should be expanded
>to include the POINT-TO-POINT option where no 
Via or Acknowledgment
>elements are used, but deliveryReceiptRequested 
attributes are turned on.
>(i.e. there is no information about whether the 
reply is sync or not in the
>message header).
>
>Your guidance 
is greatly appreciated.
>
>Regards,
>Cait
>
>Cait 
Crawford
>B2B Integration
>IBM Research
>Hawthorne, 
NY
>
>
>
>------------------------------------------------------------------
>To 
unsubscribe from this elist send a message with the single 
word
>"unsubscribe" in the body to: 
>
>------------------------------------------------------------------
>To 
unsubscribe from this elist send a message with the single 
word
>"unsubscribe" in the body to: