OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[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.

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC