Re: 1.0 Questions (some belated comments)

[Arvola Chan <arvola@tibco.com>]

Himagiri:

Please see some of my belated comments bracketed by <ac>
and </ac> embedded below.

Regards,
-Arvola

-----Original Message-----
From: Martin W Sachs <mwsachs@us.ibm.com>
To: Himagiri Mukkamala <himagiri@sybase.com>
Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Wednesday, August 22, 2001 11:31 AM
Subject: Re: 1.0 Questions


>
>Himagiri,
>
>I have embedded responses to some of your questions below.  I assume that
>others will also reply.
>
>Regards,
>Marty
>
>***************************************************************************
**********
>
>Martin W. Sachs
>IBM T. J. Watson Research Center
>P. O. B. 704
>Yorktown Hts, NY 10598
>914-784-7287;  IBM tie line 863-7287
>Notes address:  Martin W Sachs/Watson/IBM
>Internet address:  mwsachs @ us.ibm.com
>***************************************************************************
**********
>
>
>
>Himagiri Mukkamala <himagiri@sybase.com> on 08/22/2001 01:25:17 PM
>
>To:   "ebxml-cppa@lists.oasis-open.org" <ebxml-cppa@lists.oasis-open.org>
>cc:
>Subject:  1.0 Questions
>
>
>
>
>
>1) How could you request a Delivery Receipt signed/unsigned
>using CPA as the governing document for messaging
>

<ac>
There is a lot of disagreement within the MSG TC on the semantics
of DeliveryReceipt. I tend to agree with David Fischer and David
Burdett that a DeliveryReceipt element is used for end-to-end
acknowledgement from the ToParty MSH to the FromParty MSH to
indicate the successful receipt of a reliably delivered message, and
not an application level message as the 1.0 MSG spec indicates.

If the delivery channel used by the sender MSH to send to the receiver
MSH calls for non repudiation of receipt, then the sender should
ask for a signed DeliveryReceipt; otherwise it should just ask for
an unsigned DeliveryReceipt.

The Acknowledgement element, on the other hand, is used only by
an intermediary MSH to indicate to the previous hop MSH that it has
received a reliably delivered message which it is supposed to
forward. Since CPP/A currently do not deal with intermediaries, it
is not possible for a sending MSH to determine from a CPA whether
it should ask for a signed intermediate acknowledgement. Instead
it must base its decision on some other local configuration parameter.
</ac>

>2) In Delivery Channel characteristics, you can only request for a
>signed
>Acknowledgment by specifying the nonrepudationofreceipt attribute.
>There is no way to request unsigned acknowledgment
>

<ac>
I think the Acknowledgement element is kind of bogus. Please
note that lines 1814 and 1815 in the MSG spec indicate that a minimal
acknowledgement message does not even need to carry an
Acknowledgement element. Unless the concept of non repudiation of
receipt by intermediary MSHs is desired and well defined, the
Acknowledgement element seems unnecessary. (This of course
assumes the Acknowledgement element is used for intermediate
acknowledgement and that DeliveryReceipt is for end to end.)
</ac>

>3) end point types is an enumeration of "login, "request", "response",
>"error" and "allPurpose".
>
>IS the assumption that these are MSH level request, responses rather
>than business level characteristics.
>
>MWS:  These are business-level endpoint types.  As far as the MSH is
>concerned, they are simply application-level messages.

<ac>
I agree with Marty that these are business-level endpoint types. Either
the application has to designate the proper endpoint, or it must indicate
to its MSH the nature of message that is being sent so that the MSH can
select the proper endpoint.
</ac>

>
>Say a MSH needs to send a regular message to trading partner,
>
>    A ---->  B
>
>    A looks up Bs' party info from the CPA and uses the "request"
>endpoint.
>
>    ON receiving the msg if B wants to validate the endpoint. He looks
>up his party info to find out the "request" endpoint and makes sure they
>both are the same.
>
>    Is this a correct assumption???
>

<ac>
I agree with your assumption.
</ac>

>MWS:  I'm not sure that the endpoint types are useful for authorization
>purposes.  We need to do a lot more work on authorization but I assume
>that it will involve certificates at a minimum.
>
>    If so!    When exactly do you use the "response' endpoint??
>
>MWS:  The response endpoint would be used for sending a business-level
>response to a message.
>

<ac>
I agree with Marty.
</ac>

>
>4) What are the endpoints used for Ping, Pong, StatusRequest,
>StatusRepsonse, DeliveryReceipt, Acknowledgment, MessageError
>Ping -> "request"?
>Pong -> "response"?
>StatusRequest -> "request"?
>StatusResponse -> "response"?
>Acknowledgement -> "response"?
>DeliveryReceipt -> "response"?
>MessageError (ErrorList)-> "error"?
>
>MWS: Any of the above which are application-defined may be associated
>with whatever endpoints the business wants to use.  The ones you suggest
>are one possibility.  Signals and MSH to MSH messages are outside the
>scope of the CPA.  Addressing of those messages should be defined in
>the Message Service specification.
>

<ac>
I believe Signals, as they are defined in BPSS, are considered application
level messages. The CPP/A attribute syncReplyMode can take on values
like signalsOnly, signalsAndResponse, etc. Therefore, I don't think they
are outside of the scope of the CPA. Intermediate acknowledgements
and end-to-end delivery receipts, used to implement the exactly once
delivery semantics of reliable messaging are purely MSH to MSH, but
they can also be piggybacked on top of application level messages.
I particularly would like to see some clarifications on the circumstances
under which piggybacking can be done in conjunction with synchronous
and asynchronous reply modes.
</ac>

>
>5) If using "request" to send business "request" messages, then MSH
>needs to know whether an incoming message is a business level "request"
>message. WHich I don't think is in MSH domain. So going back to question
>3, can someone give an use case of how a MSH would use request, response
>endpoints
>
>MWS:  Again, the endpoint types are not the concern of the MSH.  The MSH
>only has to distinguish between messages intended for itself (the signals
>and
>any Message-Service-defined messages) and messages intended for the
>application.
>

<ac>
 I agree with Marty that the receiver MSH does not have to validate that
an incoming application level message is sent to the proper endpoint. It
needs only make sure that MSH level messages are sent to the correct
endpoint. I think your choice of endpoints for MSH level messages is
reasonable.
</ac>

>
>Thanks
>-himagiri
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>