[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
Sorry I missed the meeting, it didn't make it onto my
calendar.
Comments:
If end-to-end, signed Acknowledgment is requested, it provides NRR
-- in the same way DeliveryReceipt does. NRR cannot be provided at the
BPSS/Application level since MSH does not pass the entire message and thus the
Application cannot generate the required Digest(s).
Since the MSH does not do any application parsing, any Business Level
receipts cannot be done at the MSH level. While the Application cannot do
NRR, it can/must provide anything along the lines of "Message verified/being
processed" (i.e. Delivery Receipt). The Application would pass this signal
to the MSH with a flag which says "sign this". While it would not be
illegal for the Application to send a signed/encrypted payload to the MSH (would
this be S/MIME?), it is not within our model to do so.
An Acknowledgment can be requested separately from Reliable Messaging
although the only difference is duplicateElimination.
I thing/agree that MSH signals should be returned synchronously for
HTTP. This should be the default. Maybe we don't need a flag,
just make this a requirement (Why would this ever be done asynchronously for
HTTP?) I think I agree with Dale. This should match the transport
method (sync for HTTP, async for SMTP) and should not change per
message.
Regards,
David Fischer
Drummond Group.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC