RE: ebXML Proof of Concept Proposal v0.5

[Dick Brooks <dick@8760.com>]

There has been some previous discussions, as Prasad indicated, regarding
this apparent "overlapping" of ebXML Message Envelope MIME headers with the
transport MIME headers.

This issue only exists with MIME aware transports, such as HTTP and SMTP.
Non-MIME aware transports do not exhibit this perceived "overlapping". I've
used the analogy of a "windowed postal envelope" to describe the use of
ebXML Message Envelope headers by MIME aware transports. In other words, the
ebXML Message envelope MIME headers can be used directly by MIME aware
transports.

The question is, are there negative ramifications from allowing the ebXML
Message envelope MIME headers to "show through" the transport envelope?

Previously, concerns have been raised that a "receiver" couldn't produce a
"correct" message digest from ebXML messages sent using a MIME aware
transport because the servlet API or CGI didn't provide direct access to the
original MIME headers of the ebXML Message Envelope. However, during the F2F
on 7/11+12 the TR&P team agreed to define the "signature block" of an ebXML
message, which excludes the ebXML Message envelope MIME headers. The latest
version of the packaging spec discusses this in section 4.7.

However, enough smart people have raised concerns with this that it is worth
investigating thoroughly. Can anyone present a business case that would
require access to the original ebXML message envelope headers. Recognize,
that the data values from the ebXML message envelope headers for
Content-type and Content-Length are easily accessible, it's the actual MIME
header identifiers ("Content-type" and "Content-Length") that are not
accessible. Can anyone think of a reason why this information is necessary
in its original form?


Thanks,

Dick Brooks
http://www.8760.com/




-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Friday, July 28, 2000 2:22 PM
To: 'marcb@webmethods.com'; ebXML Transport Mailing List
Cc: Askary, Sid; ebXML POC Mailing List; Patil, Sanjay
Subject: RE: ebXML Proof of Concept Proposal v0.5


List-Unsubscribe:
 <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
 <mailto:ebxml-transport-request@lists.ebxml.org?body=help>


Marc Breissinger [mailto:marcb@webmethods.com] wrote:

It is not too late.  Part of the reason for building the proof of concept
and the demo environment is to highlight any practical implementation issues
with the specification.  I believe that this would certainly qualify.
Perhaps this topic should be added to the agenda the TR&P working group
meeting in San Jose for discussion.  It really does not affect the ebXML
specification at all -- only the mapping to particular transports.  Today,
those mappings are represented in the packaging specification by two example
messages.  At the very least, I would propose that at the meeting, we push
for making official "sections" to the document that show specifically how
the ebXML message is bundled inside the transport envelopes of the big three
transports: HTTP, SMTP and FTP.  That would make the mappings unambiguous.

Marc

Hi,

This had been an issue that I had also been raising since the time this was
first proposed. Here is an exchange that Dick and I had, that kind of sheds
light on Dick's thinking and reasoning for this approach. I am still
inclined to think however, that a separate transport envelope is better.

Prasad

 -----Original Message-----
From: Dick Brooks (E) [mailto:dick@8760.com]
Sent: Wednesday, April 26, 2000 10:14 AM
To: Prasad Yendluri
Cc: Ebxml; dick@8760.com
Subject: RE: Latest packaging spec...


Hi Prasad,

see inline comments marked with <db></db>

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Tuesday, April 25, 2000 5:07 PM
Subject: Re: Latest packaging spec...



Hi Dick,


I have couple of comments.


The Message Structure (sec 4.2) shows the "Transport Envelope" encasing the
"ebXML Message Envelope", which is consistent with the (latest) Message
Header Specification also. 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:


1.	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.
<db> Yes, I see your point. However the alternative to the current approach
would require us to create and register a new multipart content-type
(because we are defining a multipart object). If we were to create a
"multipart/ebxml" content type, as a replacement for multipart/related,
would this remove the "blur"?</db>

2.	When other transports like FTP are used, we will deliver the entire
mime/multipart message with the message envelope headers. That would make
the delivered goods inconsistent between the two kinds of transports.
<db> I disagree, the FTP transport is simply different from other transports
in that it is not "MIME aware" and does not attempt to define the type of
data being sent (other than generically binary or ascii). ebXML implementers
will have to "adjust" to the requirements of each transport they plan to
support. In the case of FTP the "RAW" ebXML message is sent without
prepending any transport specific MIME headers whereas SMTP and HTTP, being
"MIME aware", makes it appear like the transport and message envelopes are
one. This is simply a side effect of "MIME aware" transports. </db>

3.	It would be desirable to allow for the flexibility of de-coupling,
delivering the ebXML Message and processing of it. An organization receiving
ebXML messages from via different transports corresponding to say different
partners, might want to deliver them all into an input queue processed by a
common processing logic. The messages delivered from all transport
mechanisms need to be in identical format for this to be possible.
<db>I believe this will be possible using the current packaging, however all
ebXML implementers must be prepared to handle transformations to ebXML
messages caused by specific transports. For example, all binary objects in
an ebXML payload must be base64 encoded if being sent via e-mail, no such
transformation is needed with HTTP. ebXML messages must be "post-processed"
following a successful transport. The actual payload and header items, once
serialized should appear IDENTICAL after "transport" level alternations have
been removed. But again, this issue is not due to current structure of the
message/transport envelopes, this relates to differences between
transports.</db>
4.	Last but probably not least.  With this mechanism, if the type of
the ebXML message ever changes (e.g. from MIME to XML), we will need to
rehash the transport envelop all over. It would be desirable to ship either
XML or MIME formatted ebXML message using the same transport envelope type.
<db>It's difficult to say what changes would be needed with a "pure XML"
enveloping scheme because one does not exist. However I do believe there
could be lots of changes to the current MIME based ebXML specification.  I
really don't believe we can avoid changing the current specification and
code base when/if an XML packaging standard arrives and is adopted by
ebXML.Even if we adopted a scheme like you describe below, it too would be
vulnerable to change under a pure XML approach.</db>

<db> In summary, I understand your concern, but I'm having trouble seeing
how an additional level of enveloping helps solve the issues you raise
above.The added envelope appears redundant with respect to FTP, plus the
ebXML group would have to register a new MIME type and define it's
behavior/structure/semantics, and this could take a fair bit of time. I
really believe the current packaging is capable of meeting the needs you
identify.</db>

 Dick Brooks

http://www.8760.com/ <http://www.8760.com/>


Hence I would like to suggest that we use a different "fixed" content-type
for the HTTP transport. For example "application/x-ebxml". Then the example
would look like,

	POST /ebxmlhandler HTTP/1.1
Content-Type: application/x-ebxml; <any params?>
Content-Length: 9293
...........etc..........


	{ The entire MIME multipart/related message goes here}


*	The content-type of the ebXML header container also needs to be of a
flexible type like the payload and not fixed at application/xml since,

1.	We expect more than one header part in the ebXML header. Per the
latest Header specification sent out by David Burdett, the header can have
parts for "Message Routing Info", "Message Routing History", "Signatures",
"Errors?" etc.

2.	Even if we think some of these headers can be sub-elements/sections
of the same XML document, it seems other parts (e.g. signatures) need to be
separate at least as of now (since xml-dsig specifications / implementations
are not mature yet). Also, it might be needed to put the routing headers in
a separate (XML) document so that it can be updated (and signed) independent
of the rest of the header sections.

Thanks, Prasad

-----Original Message-----
From: Marc Breissinger [mailto:marcb@webmethods.com]
Sent: Friday, July 28, 2000 10:53 AM
To: Prasad Yendluri; Patil, Sanjay
Cc: ebXML Transport Mailing List; Askary, Sid; ebXML POC Mailing List
Subject: RE: ebXML Proof of Concept Proposal v0.5


It is not too late.  Part of the reason for building the proof of concept
and the demo environment is to highlight any practical implementation issues
with the specification.  I believe that this would certainly qualify.
Perhaps this topic should be added to the agenda the TR&P working group
meeting in San Jose for discussion.  It really does not affect the ebXML
specification at all -- only the mapping to particular transports.  Today,
those mappings are represented in the packaging specification by two example
messages.  At the very least, I would propose that at the meeting, we push
for making official "sections" to the document that show specifically how
the ebXML message is bundled inside the transport envelopes of the big three
transports: HTTP, SMTP and FTP.  That would make the mappings unambiguous.

Marc

-----Original Message-----
From: Patil, Sanjay [mailto:Spatil@netfish.com]
Sent: Friday, July 28, 2000 12:45 PM
To: 'marcb@webmethods.com'; Prasad Yendluri
Cc: ebXML POC Mailing List; 'dick@8760.com'; Askary, Sid
Subject: RE: ebXML Proof of Concept Proposal v0.5




[Marc]   This does bring up a larger issue on maintaining the separation of
the ebXML Message Envelope from the transport envelope.  For example, if we
truly maintained the spearation of the ebXML MIME message envelope from the
transport envelope, an HTTP transport ebXML message would look like the
following:
 <snip>

[Patil, Sanjay]  This is an interesting point, Marc. I was myself thinking
about this issue last
couple of days trying to find any convincing reasons for mixing the
transport envelope and
the  ebXML message envelope. Does anyone on the mailing list know the
rationale behind
this decision. If it's not too late, may be we should consider a change as
the mix of the
headers from the two unrelated envelopes is going to cause issues ...
1>Difficulty in using MIME and HTTP APIs together. Service implementers will
have tough
    time creating valid ebXML s=642132016-28072000>    time creating valid
message. Typically
    APIs which make the HTTP request available to applications have separate
set of APIs
    for accessing headers and the body. This will make it difficult to use
MIME APIs which
    in their simplest form would like to suck in the whole MIME message
including headers
    and body from a stream. Also, a valid MIME message needs to have the
mandatory
    header "MIME-Version: 1.0". Service implementers will have to hand code
insertion of this
    header while instantiating the MIME message.
2> Any future wrappers for ebXML message can not be accommodated. ex.
Rosettanet has
     the concept of RosettaNet object in which the Rosettanet MIME message
is nicely
    encased along with detached signature, etc. The RosettaNet object is
then considered
    as the body of the HTTP message. With this next version of RosettaNet
are free to modify
    the structure of the RN Object without breaking transport level
processing in the services.
3> There might be cases of conflicting headers between transport and ebXML
message
     headers. Or simply put, we are leaving ebXML message at the mercy of
the HTTP engine
     which may modify or alter the sequence, etc of the ebXML message
headers.
4> Transport independence, which will affect the processing flexibility at
hubs.


May be it's still not too late.

thanks,
Sanjay Patil
Netfish Technologies.

============================================================================
=====================================


5. If SMTP is part of the Hub model, I am not sure if we can guarantee "hub
should not cause any alteration of the envelope, header or payload of the
messages". I mean SMTP (mail) servers are likely to add additional headers
to the (transport) envelope, which gets into the message envelope also (per
ebXML scheme)!

The point was that the hub should not alter the ebXML message envelope,
header or payload.  The transport envelope can be modified at will.  In
fact, part of the value add of the hub could be to connect partners that
support different protocols that otherwise would not be able to talk to each
other.  This does bring up a larger issue on maintaining the separation of
the ebXML Message Envelope from the transport envelope.  For example, if we
truly maintained the spearation of the ebXML MIME message envelope from the
transport envelope, an HTTP transport ebXML message would look like the
following:

POST destination-server- ebxmlhandlder-URI HTTP/1.1 <?xml:namespace prefix =
o ns = "urn:schemas-microsoft-com:office:office" />
Host: destination-server-domain:destination-server-port
Content-Type: multipart/related;
              charset="iso-8859-1";
              boundary= transport-envelope-boundary
Content-Length: int-length [units based on content-transfer-encoding]

-- transport-envelope-boundary

Content-Type: multipart/related;
               type="application/vnd.eb+xml";
               charset="iso-8859-1";
               version=0.1 ;
                            MIME-Version=1.0 ;
               boundary=ebxml-envelope-boundary
Content-Length: int-length [units based on content-transfer-encoding]

-- ebxml-envelope-boundary

Content-ID: uid@originator-domain
Content-Length: int-length [units based on content-transfer-encoding]
Content-Type: application/vnd.eb+xml

<?xml version="1.0" encoding="UTF-8"?>
<ebXMLHeader>
 ....
</ebXMLHeader>

--ebxml-envelope-boundary

Content-ID: uid@originator-domain
Content-Length: int-length [units based on content-transfer-encoding]
Content-Type: ???/???

< Payload >

         --ebxml-envelope-boundary--

--transport-envelope-boundary--

This scheme would allow for a hub to route a message without affecting the
ebXML message envelope.  The hub could switch protocols from HTTP to SMTP to
FTP to whatever without affecting the ebXML envelope.  However, the current
packaging specification mixes the definitions of the ebXML message envelope
with the transport envelope and we should follow the specification.  Thus, I
suppose we have to allow the hub to alter the ebXML envelope (much to my
dismay).