On Blurred distinctions in the Latest packaging spec...

["Dale Moberg" <Dale_Moberg@stercomm.com>]

<Prasad>  However section 4.7 "complete example of .. ebXML
message .. sent via HTTP POST", brings in the
complete ebXML Message Envelope into the transport
envelope. I mean the headers like, "Content-Type: multipart/related;
 type=ebxml", "Content-Length" etc. are made part of
the MIME headers for the HTTP POST. This, I think is
undesirable for the following reasons This blurs the distinction
between the two envelops. The transport mechanism should simply
"transport" and "deliver" the entire "ebXML
Message Envelope" with its constituent parts as is.
</Prasad>

Dale Moberg>> This issue seems familiar somehow...
In both SMTP and HTTP, the PDU (protocol data unit) is
a message composed of two overall parts,
the headers and the body. The syntax for delineating the parts is
the first occuring string of CRLFs ("the first blank line").
Let  us say that the information for the transport part
is the headers and for the next service layer, the body.
(This next service layer is the MIME parser/handler layer.)
The body is of course structured as a MIME body.
How does the transport service layer know
how to _deliver_ (or specify delivery)
of the MIME body without reading beyond its part?

The answer is that the MIME content type for the
body is included in the transport headers. This
header information provides  part of the interface
between the service layers (the transport header
handlers and the bodypart handlers). Other more
specific APIs (CGI for example) provide other
interfaces between the services levels also,
of course.

 While in some sense the interface does "blur" the boundaries
between processes, any interface between modules
does that. An interface is essential for
connecting the layers. I do not therefore think
that the blurring here is undesirable.

Furthermore this way of packaging is standard for
MIME packaging. Because MIME packaging is
not likely to go away unless HTTP and SMTP are
drastically revised, we should use it in accordance
with the conventions that are well established
in the IETF and not invent yet another container
to put mulitparts inside.