I'm
not sure, but I think David and I are responsible for making documentation changes from this point forward, if so I'll be happy to make the changes listed here.
Rik,
is document change control back in the hands of the editors
now?
First, kudos to the team that reworked the two specs
into one cohesive document, excellent work.
I've found just a few minor
corrections:
Line
198, replace "multi-part" with "multipart"
Line
200, replace "four" with "two"
Line
202, replace "4" with "2"
Line
213, remove "version=0.1" from the example.
Line
221, insert a ";" before boundary
Line
221 remove the spaces before and after
"application/vnd.eb+xml"
Add
the following to section 2.4:
"The header body part MUST occur as the first (a.k.a. root) body
part in an ebXML message.
In
section 2.4.2 replace lines 243, 244 which reads,
"The
Content-Length header is a decimal value used to identify the total number of
OCTETS
contained in all constituent message body parts, including body part
boundaries.
Example:"
WITH
"The
Content-Length header is a decimal value used to identify the total number of
OCTETS
contained in the ebXML header document (excluding body part
boundaries).
Example:"
Line
254, replace "0.1" with "1.0"
Line
256, replace "iso-8859-1" with
"UTF-8"
Line 259 remove the spaces between "charset" and "=" and
“UTF-8”
Lines
200/301 replace
"The
Content-ID MIME header identifies this instance of an ebXML is used to
uniquely identify an instance of an ebXML message payload body part.
"
WITH
"The
Content-ID MIME header is used to uniquely identify an instance of an
ebXML message payload body
part."
Section
2.5.4, we need to specify that encryption is also
allowed.
Also
in section 2.5.4, we should specify that implementers SHOULD indicate the
character set used within the payload when the content-type permits the
inclusion of the "charset"
parameter.
Line 311, replace
"header" with
"payload".
Line 313, replace
"application/vnd.eb+xml" with
"application/xml"
Replace lines 351/352 of the example with "Content-Type:
multipart/related; type="application/vnd.eb+xml";
boundary="8760"
Line 370 replace
"he" with
"the"
General
comments:
It seems redundant to
have a version parameter in the Content-type header of the ebXML header and a
version attribute in the ebXMLHeader root element of the ebXML header
document. I suggest we place version in one or the other, but not
both.
I really like the
enhancements to DocumentId, very nice
indeed.....
We need to provide a
complete list of possible values for the "context" attribute within the
PartyId element. I believe ISO has a specification for this, William K, can
you provide pointers to that document
(thanks).
I
believe the MessageData element should also include a "DeliveryDeadline"
element which indicates the last instance in time a message can be delivered
to an intended recipient and a "ResponseDeadline" element to tell the
receiver how long they have to send an acknowledgement. I believe it would
also be valuable to indicate how an acknowledgement should be delivered
with an OPTIONAL "AcknowledgeTo" element (e.g.
<AcknowledgeTo>mailto:ebXMLacks@8760.com</AcknowledgeTo> or
<AcknowledgeTo>http://ecommerce.8760.com/servlets/ebXMLackHandler</AcknowledgeTo>
or <AcknowledgeTo>synchronous</AcknowledgeTo>). The example using
"synchronous" indicates that an acknowledgement should be sent on the same
session that was used to send the ebXML message. If the AcknowledgeTo element
is not present then whatever was specified in the TPA determines how
acknowledgements are delivered.