Comments on ebXML Messaging Service, 0.1

[Henry Lowe <hlowe@omg.org>]

Comments on TRP ebXML Messaging Spec.
Henry Lowe, OMG

a) line 153: as there is no other ebXML enveloping than MIME, change the "for
example MIME ..." to "i.e., MIME ...".

b) figure in section 2.1, put a reference on it such as Figure 2-1.

c) lines 199-201: 199 says there are four attirbutes, but only two are listed,
i.e., type and boundary (items 1 and 4  2 and 3 are missing).

d) lines 204-205: If there is only one valid value, the text "is an example
usage of the" should be changed to "line must be included for".

e) line 220: " application/vnd.eb+xml " should be changed to
"application/vnd.eb+xml", i.e., remove the spaces after and before the ".

f) lines 224-225: Can there be more than one header?  If no, the text "There
MUST be one ebXML header ..." should be chnaged to read "There MUST be one and
only one ebXML header ...".

g) line 241-244: Is this value the same as the value in section 2.3.2?  It
sounds like it is.  If it is, so state.

h) line 253: while the version of this document is 0.1, the final released
document will be 1.0.  Change ""0.1"" to ""1.0"".

i) line 256: Is ISO 8895-1 identical to UTF-8?  If so, perhaps this should be
noted.

j) lines 259-268: Do we want to say anything about multi-hop transmission of
messages?  For example "NOTE: In the case of multi-hop transmission (e.g.,
bridging), it will be necessary to de-crypt or re-sign header documents at
intermediate forwarding nodes."

k) lines 299-300: some words are missing, but it’s not clear what  please fix.

l) line 303: in the example, is "ebxmlpayload" required?  If not, how do you
know that this part contains a payload?  There is no attribute saying this is a
payload.

m) lines 334-355: Is the Message digest some sort of check sum such as a CRC? 
If so, where does it go in the message?  

n) line 356 and elsewhere: Section headers, such "3 Message Header" should
match the boxes in figure 2-1 in section 2.1.  For example, this section should
be "3 ebXML Header Document".  Make it much easier to read the document.

o) lines 372-373: The first sentence isn’t entirely clear.

p) lines 449-467: Two comments on these lines:
1. PartyId is not defined completely and, more importantly, the parameter
"context" is not defined except in what can be derived from the example. It
would seem from the example, that the address 12345 is a valid address for an
underlying transport which recognizes and uses DUNS numbers to message
delivery.  If this is the case, then the "context" parameter would seem to
reflect the mapping onto the underlying transport and a message to be sent over
a CORBA transport, you would have, for example
<To>
   <PartyId context="corbalocURL">555xyz.com/Prod/TradingService</PartyId>
</To>

2. This is not unrelated to the issue of routing.  This document says nothing
about how routing is handled or reflected in the message header.  If we are
using source routing (i.e., the message originator or perhaps the TPA defines
the route the message will take to the destination).  Presumably a full set of
source routing information will need to be contained in the header or perhaps
in subheaders containing the route when the route comprises more than a single
hop.  This set of routing information would have to contain the necessary
"context" for each transport in the case of different transports being used for
different hops, e.g., hop-1 uses HTTP, hop-2 uses CORBA, hop-3 uses MQSeries,
and hop-4 uses SMTP (OK, perhaps this is a bit complicated, but the header
information structure should be able to support this  heaven knows what the
real world may turn up).

Sorry, but I have not worked out a solution to p2.  However, unless someone
already has a solution, I will be happy to work on this.