[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: TRP Messaging Service Specification
|
I sent
these comments to the list on Sunday, 8/13, but they never appeared, so here we
go again....
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.
Dick Brooks
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC