RE: Initial (mostly editorial) comments on TRP 0.92

[Rik Drummond <rvd2@worldnet.att.net>]

thanks for the thorough comments.... rik

-----Original Message-----
From: rsalz@CaveoSystems.com [mailto:rsalz@CaveoSystems.com]
Sent: Friday, January 19, 2001 2:46 PM
To: chris.ferris@east.sun.com; ebxml-transport@lists.ebxml.org
Subject: Initial (mostly editorial) comments on TRP 0.92


I am a newcomer to ebXML, so please excuse if I've touched on any sore
points.  I have been involved with network protocols for many years, and
approached this document as a potential implementor.  Therefore, many of
the suggestions might be wrong, because I do not understand the document.
I think most of them are okay, however.  It's the big question at the
end that gives me the most problem.  If I'm not way off-base, I hope to
finish my line-by-line review by Tuesday morning.

Editorial
Delete lines 2-7, since it's a duplicate of 91-93 (and internally
contradictory unless "separate document" on line 6 becomes "separately").
As a consequence of this, remove line 8 and renumber accordingly.

Editorial
Line 20, replace "placed into the body of" with "sent over a"

Editorial
Line 34, strike "complete".
Line 34, should "requirements" be "semantics"?

Editorial
Line 39, replace "contains" with "contains a non-normative"

Editorial
Lines 40-41, need the word "normative" or "non-normative" somewhere.

Editorial
Lines 46-48.  Use typographic onomotopoeia, putting "Italics" in italics,
etc.

Editorial
Lines 52-74.  Should be reformatted to more clearly indicate that they
are an excerpt from RFC2119.

Editorial Question
Lines 82-92. How do these compare with the documents mentioned in lines
110-116?

Editorial
Line 84. Change "of the" to "on these"?

Editorial
Lines 115-116. Change "that includes: ..." to "; the other two are ..."
and strike the last five words.

Editorial
Lines 121-123. Reword to indicate this is one possible architecture, not
a required architecture.  Consider separating the "applications" and
"interface" boxes, as is done with the transport box -- that would help
emphasize what this particular document is defining.

Editorial
Line 130ff.  Change "of:" to "of two parts:". Consider capitalizing the
first words of lines 130 and 131 and putting "and" at the end of 131
and 134.

Editorial
Line 135. replace "an optional, single" with "at most one".

Editorial
Lines 136-137. Isn't it the actual payload of the "ebXML application"?

Editorial Question
Figure at line 138. What is the difference between "ebXML Header Container"
and "ebXML Header Envelope".  Should the latter be in a yellow box
analogous to the "ebXML HEader Document (XML)"?  And the same question
for "Payload" except I assume the color would be baby blue. And, now that
I look at it further, the should the "ebXML Message Envelope" also be
in a box?

Editorial
Line 141. Remove comma after "standard."  Or remove "standard," altogether.

Editorial
Line 144 is confusing.  Pragmatically, MIME can carry anything. Is the
intent better expressed by "contents of the payload are up to the user
of the ebXML service"?

Editorial
Lines 145-146 are confusing. It implies Appendix C only talks about the
Message envelope, when it's already been made clear it addresses ALL
the transport issues.  Consider deleting them.

Editorial
Lines 147-149. RFC2045 discusses the quoting rules and these lines here
are a little misleading (cf lines 170 and 177 where quotes are mandatory).
Consider deleting them and renumbering accordingly.

Editorial
Line 158. The trailing semicolon is in error since there are no parameters.

Editorial
Line 159. Replace "contains" with "MUST contain"

Editorial
Line 170 appears to use "-" not "=", but it could just be my printer.

Editorial
Line 177. The colon should be removed.  As at least one other person has
pointed out, the "8760" should be replaced with someone neutral, like
"hashxxxxxxx@ebxml.org"

Editorial
Line 180. Shouldn't the "SHOULD" be a "MUST"?

Editorial
Line 186. The trailing semicolon is in error.

Editorial
Whooah, nellie.  I started to read lines 188ff and I am now totally
confused.  It's those two bullets at 189 and 190.  Is the header
document contained in the header envelope, or a peer of it?  I assume
contained, in which case line 190 should be joined in-line to 189.

But my confusion continues.  Is the Message Envelope (section 7.2)
intended to be in "transport headers" (for lack of a better term)?
	From: purchasing@bigcorp.com
	To: server@catalog.com
	Mime-Version: 1.0
	Content-Type: multipart/related; "type=application/vnd.eb+xml";
	    "boundary=ebxml-part-wrapper"; version="0.92"

	This is an ebXML mime message.

	--ebxml-part-wrapper
	Content-Type: "application/vnd.eb+xml"; version="0.92";
	    charset="utf-8"
	Content-ID: <po-request-22222-header@bigcorp.com>

	<ebXMLHeader xmlns="....">
		...
	</ebXMLHeader>

	--ebxml-part-wrapper
	Content-Type: application/xml
	Content-ID: <po-request-22222-body@bigcorp.com>
	Content-Transfer-Encoding: base64

	12465AB34C.....

	--ebxml-part-wrapper--

*OR* is it further wrapped?  For example:
	From: purchasing@bigcorp.com
	To: server@catalog.com
	Mime-Version: 1.0
	Content-Type: application/ebxml; boundary="transport-outer-wrapper"

	This is the transport shovelling MIME at you.

	--transport-outer-wrapper
	Content-Type: multipart/related; "type=application/vnd.eb+xml";
	    "boundary=ebxml-part-wrapper"; version="0.92"

	This is an ebXML mime message.

	--ebxml-part-wrapper
	Content-Type: "application/vnd.eb+xml"; version="0.92";
	    charset="utf-8"
	Content-ID: <po-request-22222-header@bigcorp.com>

	<ebXMLHeader xmlns="....">
		...
	</ebXMLHeader>

	--ebxml-part-wrapper
	Content-Type: application/xml
	Content-ID: <po-request-22222-body@bigcorp.com>
	Content-Transfer-Encoding: base64

	12465AB34C.....

	--ebxml-part-wrapper--
	--transport-outer-wrapper--

It's possible to argue either way, I suppose.  MIME-aware protocols
such as SMPT, HTTP, and BEEP, could easily and automatically dispatch
to ebXML handlers, while non-MIME-aware (MQSeries, FTP, LDAP, etc)
can share the same ebxml 'packets'.  And SMTP could, for example,
leverage multipart/alternative.

I believe my confusion has been worsened by the header and envelope
terms.  I suggest replacing the concepts of envelope with MIME headers,
container with MIME bodypart, etc.  Remove the level of abstraction
and go straight to the implementation.

Thanks for taking the time to read this far.
	/r$