[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: On Blurred distinctions in the Latest packaging spec...
<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.
Powered by eList eXpress LLC