RE: comments on David's proposed changes

[Dick Brooks <dick@8760.com>]

David/Chris,

Generally I think it's a good idea to separate Ack's from Delivery Receipts,
so I'm in favor of this change. However I do have a few questions/comments
about the design.

Regarding the mustUnderstand attribute, please remove mustUnderstand from
ALL elements contained in the SOAP Body, it is completely unnecessary (the
SOAP spec says that everything in the SOAP Body is ASSUMED to be
mustUnderstand="1" by default).

I also want to propose that we REMOVE all version attributes used to
indicate the ebXML version and simply use the Namespace declaration to
indicate the version. For example, if the namespace URI were to become:

xmlns:eb='http://www.ebxml.org/namespaces/messageHeader-V0.98b'

The entire message would be associated with the correct version of ebXML and
this would eliminate a lot of extra work.
this would also eliminate the possibilities of "mixed versions" within a
single message.

Are we changing the semantics of DeliveryReceipt? My understanding of a
Delivery Receipt is that it was
sent by the "to" party to the "from" party AFTER THE PAYLOAD WAS DELIVERED
TO THE APPLICATION.  When I read the proposed changes it appears that a
DeliveryReceipt is sent by the "To" party "to let the From party know that
the message was received". This looks very similar to the purpose of an
"Acknowledgement", it simply acknowledges receipt of the data by the To
party, not that the data was delivered to the application. Is my
understanding of this change correct? If it is then we really only need one
type of "Acknowledgement" (a delivery acknowledgement).


I'm assuming that a DeliveryReceipt is sent in a ebXML message, which
includes a MessageHeader, where the FROM party is the entity
generating/sending the Delivery Receipt and the TO party is the party that
will receive the Delivery Receipt. If this is correct then I don't think we
need a FROM party in the DeliveryReceipt.

More information is needed with regard to errors. For example, what happens
if the calculated DigestValue is different from the DigestValue in the
Reference for a payload. I assume a ErrorList/Error is generated and this
would be sent in lieu of a DeliveryReceipt. In general, I think we need to
"beef-up" the error section by listing the possible errors that can occur
within the ebXML MS. It will also help interoperability if everyone uses the
same error messages consistently.

Lastly, it seems to me that DigestValue can occur more than once in a
DeliveryReceipt. I believe it can occur once PER Reference from the original
message Manifest.

Regards,

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: cferris@xtacy.East.Sun.COM [mailto:cferris@xtacy.East.Sun.COM]On
> Behalf Of christopher ferris
> Sent: Thursday, April 12, 2001 11:06 PM
> To: ebXML Transport (E-mail)
> Subject: comments on David's proposed changes
>
>
> All,
>
> I have attached a marked up version of David's proposed change for
> separation of Acknowledgment and DeliveryReceipt. Save for the
> comments I made in the attached, I am fine with the changes as
> proposed. Nice job David!
>
> As for the proposed change for support of RefToMessageId in the
> context of a Message Status query, I am confused. Is the RefToMessageId
> solo in the SOAP:Body with merely the Service/Action to identify the
> request? What about the response message that includes the StatusData
> element. Shouldn't the StatusData element be augmented with the
> RefToMessageId of the message being queried and the
> MessageHeader/MessageData/RefToMessageId refer to the MessageId of the
> request message (as opposed to the MessageId of the message being
> queried)?
>
> David, can you please comment?
>
> Thanks,
>
> Chris
>