RE: Comments on 0.21

["Burdett, David" <david.burdett@commerceone.com>]

Forwarding to the Transport list

David

-----Original Message-----
From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de]
Sent: Monday, October 09, 2000 12:58 PM
To: knaujok@pacbell.net; Burdett, David
Subject: FW: Comments on 0.21


Hello Klaus or David,

attached is my Comment to the Messaging Service Specification. I was unable
to send to the List Address cause lists.oasis-open.org does not exist (as
proposed on the web page) and lists.ebxml.org does not allow for
non-subscribers to mail to the transport list (only subscribed to the
architecture list).

I tried to send my comments to Rik, but somehow i did not get back a
response. So can u make sure the text is reviewed by the transport guys?

Greetings
Bernd

-----Original Message-----
From: Eckenfels. Bernd 
Sent: Monday, October 02, 2000 6:25 PM
To: 'ebxml-transport@lists.ebxml.org'
Subject: Comments on 0.21


Hello,

i have some comments on 0.21 to make the document a bit more clean and
make the specification less troublesome for ad-hoc communication. And
even add some more flexibility if we want to use mailbox/VAN routing.

412-414:
i would allow the PartyID Element to occur multiple times, so you can
give all the known contexts. This will enable us to se a DUNS Number, a
ILN Number, a TAX Code a Company Name, a e-mail Address, a van mailbox
id and so on. This is especially good for routing.

451-453:
if there is no earlier message we should require the element to be not
present, not to be empty. Or if we want to have it empty but present,
then we should tell this explicitely: if there was no former message the
ELEMENT has to be present and be empty </ RefToMessageID> or
<RefToMessageID></RefToMEssageID>. Personally I think we should require
the element to be skiped if it is empty.

We should also define what kind of message we are referencing to:
a order change can reference to the order send or it can reference to
the order-dis-acknowledgement of the partner. PErhaps we should allow
the RefToMessageID to be repeatable and add an additional Attribute:

context=
answer: the Referenced Message ID is a message ID generated by you and
we answer to it
prev: the Referenced Message ID is a message id from us and we send the
next message to is
root: the Reference Message ID is the first message of a new business
process and we reference it for better threading

or something like this.

460: we should state who will interpret the ReliableMesssageInfo field
and what he should do with it. In the enumeration we should also add the
"AtLeastOnce" or something like this. Cause this is the normal way
transmission protocols without duplicate checking will work (SMTP for
example). 
Filtering duplicates should be responsebility of the endpoints.

551-591: i would allow the following elements to be optional: (the
reason for this is it is better to allow them to be removed than
everybody is making something "up" to fill in them.
TPAInfo, ReliableMessageInfo, ServiceInterface , Action, ConversationID,
make RefToMessageID (0-n)=*

In the DTD you are using fixed attributes to describe the data types of
the elements e-dtype... if you do so, you should mention where this is
defined, othrwise skip them.

Mit freundlichen Grüßen
SEEBURGER AG
Bernd Eckenfels
-- 
SEEBURGER AG, Edisonstrasse 1, D-75015 Bretten, Germany
Fax:+49(0)7252 96-2222  Fon:+49(0)7252 96-1256  http://www.seeburger.de/
We integrate B2B Solutions